The Right Approach to a Legal Document Management Project

Like all IT projects and new business initiatives, a legal document management search should begin with a business problem and end with a solution, not the other way around. Interviewing vendors and products before establishing the goals and requirements of the project usually leads to unjustified expenses and wasted time.


That’s not to say some research doesn’t help to inform requirements gathering. Knowing what’s possible in general terms will make the requirement realistic, but that information shouldn’t be allowed to pollute the conversation and skew the requirements toward justification or toward a particular product.


Conversations about a business problem should remain product neutral and vendor agnostic as late as possible. Before considering solutions, build a requirements document that describes the current environment, causes of the problem, and the firm’s tolerance for change and additional expenses should be understood.

Starting to consider document management systems

A document management system solves certain kinds of business problems, namely problems with collaboration, email bloat, compliance, knowledge share, archiving, document retention, or simply finding documents. Because of the expense of these systems, firms will typically need to have problems in more than one area to justify a new document management system, though a problem with finding documents is the starting place for most firms.


Considerations of the current document management system, if even just Windows folders and naming conventions, will also help inform the choice of a new system. For instance, if losing documents is a problem because no one bothers to follow naming conventions, then a document management system that is cumbersome to use when saving new documents won’t fit well. If email inbox bloat is a primary concern then the system will need a quick way to save messages.


Once the business problem and primary goals have been defined, then the criteria for evaluating new systems should be obvious. Pick the system that best addresses the issues the firm actually has, not the bells and whistles that aren’t listed on the formal requirements document.

What not to do

The inverse of this is to start looking at document management systems and then try to justify the cost by exaggerating the problems it solves and minimizing the problems it doesn’t solve. Most commonly, firms do this when trying to justify staying with the same product or vendor through an upgrade. If the product isn’t working, then it should be scrapped and replaced by something that is worth its investment.


Technology is supposed to be an asset to a company, not just another utility that needs to be paid. Expect more from your software, and put it in writing through a formal requirements document.