How to Evaluate a Vendor

Unless you've done a full discovery process, generic vendor-provided survey/ROI reports are fairly meaningless. One of the ways that I've found to really learn about a product is to try to get enough funding to take one of the vendor's low-level training classes. It's a lot cheaper than buying a product and then finding out it didn't hold up (why does any company think it's a good idea to just buy and find out?).

The training class method is good, because, when they're training you on a product, you usually have someone who knows the product inside and out. This gives you a direct channel to ask better questions and get the real answers.

Gathering requirements is a difficult task, but it's something that we do every day. There are always some general requirements that fit with nearly every single-sourcing project. Here's a brief list of the kinds of requirements you'll want to consider. It is by no means a complete list:

• General System Requirements
• Additional Tool Requirements
• Workflow Requirements
• Performance Requirements
• Data Object Requirements
• Network Requirements
• Benchmarks for Requirements Verification

These are the underlying requirements that define any good system: the ability to control document source, the ability to create and produce documentation products for customers.

The goal of a good requirements document is to capture and define requirements for a new system above and beyond these basic requirements. A good requirements document includes these basic, best practices requirements, in addition to the problem-specific requirements that can only be defined in terms of your business processes and needs.

These are the kinds of requirements will help to ensure a system that encourages user participation. It helps you to design a system that can provide real benefits to the user and to the company. A well-designed system will provide many opportunities for small efficiencies in addition to any benefits due strictly to upgrading to new technology.

It is my intention here, then, to lay out some best practice requirements, to get requirements documents writers started. This is a jumping off point. Not an end point. The real end point includes all those intangibles that only you know about as the in-house expert, the requirements document writer.