In a previous post I explained the importance of gathering requirements at the start of a project. In this post I'm going to discuss the relationship between certain requirements and different document assembly solutions.
Document assembly systems work by prompting users to provide information. However, the mechanisms for prompting users can range from rudimentary mail merge-type interfaces at one end to dynamic Web Wizards at the other.
How slick the interface needs to be depends to a great extent on the expertise of the person answering the questions. A senior lawyer drafting a familiar document will be more comfortable with a system that gives them direct access to the documents as they're drafting. In contrast, an inexperienced business user will prefer an intuitive system that only asks a few questions at a time which - along with important guidance information - are easy to understand. This means it's important to clarify who will be using the system(1).
Note: Document assembly, by its nature, enables non-experts to create documents that would previously have been done by a lawyer. So don't assume that those who previously drafted the documents will still be the ones doing so.
Some document assembly systems are intended for a handful of users producing simple documents. Others are designed for use in large organizations such as Fortune 500 companies, top law firms and government agencies.
The appropriate system for you will depend on both your current situation and on possible future requirements. Your initial project should be well-defined. Once you've successfully delivered that, then look to handle a bigger challenge - that could involve additional users, more complex documents, or greater integration.
Note: Any system can address the easy stuff. Make sure at the outset that you choose a system that can scale(2) to handle what you might ultimately require.
If you only need a short term throw-away solution, template maintenance isn't a major issue. However, once you start automating more documents - or even end up relying on a system for longer than anticipated - maintenance suddenly becomes the ONLY issue.
Note: Make sure you understand how easy it will be for you to maintain templates (3) in five years after they've been modified umpteen times. Creating a template from scratch is easy. Modifying it to handle unexpected changes - that's the real challenge.
Which brings us to support. Support is an essential consideration (4) - particularly if you're planning to rely on the vendor for a number of years. The keys here are expertise and accessibility.
True expertise encompasses technical ability (knowing how to implement and use the system), subject matter expertise (knowing how users of the system do their jobs), and industry knowledge (understanding of the broader industry context).
For a vendor to be accessible they ideally need to operate in your geography and/or timezone. However, just as important is responsiveness. How passionate are they about truly trying to solve your problems? How willing are they to go that extra mile?
Note: Great support doesn't just happen. Expertise is born from years of hard work, learning and refinement. And responsiveness comes down to a vendor's culture as much as anything.
The bottom line is that it is essential to gather your requirements AND to match them to the appropriate solution before starting your document assembly initiative. Document assembly software comes in many shapes and sizes, from simple desktop add-ins and products to enterprise-strength online solutions. Understanding which best meets your needs is key to a successful implementation.