Comtech Services, Inc.
At Comtech, we often come across companies who ask us to submit a proposal to help them improve their publications environment or to select a new Content Management System (CMS) because their current CMS or process is not working as they hoped it would. During our initial conversations, we ask to look at the requirements for their CMS. Often, the response is “We don’t have requirements that we developed for the CMS,” “Our IT department developed the requirements; you are more than welcome to look at those,” or “The CMS vendor helped develop ‘requirements’ describing what their system could do for us.”
What we recommend for those seeking a CMS and a structured authoring tool is to develop an initial set of requirements specifically for their organization. Developing requirements doesn’t mean just a brainstorming session with a few technical writers trying to define what is needed by the group. It means talking to all stakeholders involved to produce a robust set of requirements.
The functional requirements are developed by the rest of the organization. Stakeholders include management, technical communicators, marketing, and anyone else who will be using the system now or in the future. Functional requirements include such categories as repository, metadata, workflow, usability, authoring, reviewing, linking, publishing, translation, search, templates, and version control.
We recommend that an initial step in developing functional requirements is to create user scenarios. This step matches the goals to specific tasks the users will be performing with the CMS. The functional requirements will also reflect the needs of many users during the content creation pipeline.
We strongly recommend that requirements be developed by many parts of the organization rather than one alone. When the IT organization alone develops the requirements for the entire organization, they tend to miss some of the critical functional requirements. In a similar fashion, when the CMS vendor writes the requirements for your organization, they come into the environment with no previous understanding of the users or their needs. The CMS vendor is driving to sell you a product. That means that they are more likely to disregard what their system does not support or assume that you need more than what you are asking for because they provide a “new” function that everyone must have.
After you develop your requirements for implementing a CMS, you need to take a few more steps. Your requirements must be prioritized. We like to use a general three-level prioritization matrix. A priority of “1” indicates a requirement that the CMS system must have to be accepted, “2” indicates a requirement which adds significant functionality to the system, and “3” indicates a requirement that is “nice to have” but not essential. It is a good rule of thumb to present this final list to the original contributors, asking them to validate the requirements. Sometimes the requirements may misstate what people intended. Or, once they review the requirements, stakeholders may want to add additional requirements.
After prioritizing and validating the requirements, it is time to ask the vendors what they have to offer. Sending the requirements in a request for proposal to a small list of vendors often filters out the vendors who will work best in your environment. We recommend that you ask the vendors to indicate if the specific requirements are provided to you “out of the box,” “through customization,” or “as a part of configuring the system.” These distinctions will help to identify the extensibility and robustness of the system. They will also indicate any additional costs you may be presented with upon purchase of the product. Prioritizing helps you budget and prepare a more accurate business case for moving to a content management-driven, structured-writing environment.
Requirements for any system being introduced into your organization should be developed by your users, both internal and external. It is essential that you develop requirements. Without them, you may end up spending more money to fix a problem or pay for costly customizing because you didn’t identify all the components at the beginning.