Using narrative in a CMS tender

Tender documents typically consist of long lists of ‘functional’ requirements to be responded to by the CMS vendor.

Experience has shown, however, that these are a very poor way in which to convey real needs, and they don’t ensure that the right product will be selected.

Instead, consider presenting requirements in ‘narrative’ format. This provide a more complete description of needs, and gives much-needed context to vendors responding to the tender.

Communicating needs

As outlined in the earlier article Goals of a CMS tender, the primary purpose of the tender document is to communicate your needs to the prospective vendors.

This means that you should do whatever is required to clearly convey the nature of your organisation’s CMS needs.

Based on our experiences with helping a wide range of organisations develop CMS tenders, we recommend:

• keeping the tender as short and as succinct as possible
• using narrative and descriptions, in preference to functional specifications, or just dot points
• writing in plain english, instead of ‘legalese’
• avoiding jargon and technical terms
• using scenarios wherever possible to convey needs

Escaping functional specifications

Most tenders are written as long lists of generic requirements such as:

The CMS must support storing content in multiple repositories, which will be deployed in Oracle. The vendor should specify the database schema used.

While this may be a meaningful requirement, it raises questions such as: what is the business need that is being met? When would this requirement be used, and how?

Worse yet, some tender consist solely of one-line dot points for requirements:

Must integrate with existing business systems.

Even assuming the requirements are meaningful (which existing systems are being integrated with, and how?), these lists rely heavily on the use of jargon, which is not consistently understood across the CMS industry.

Narrative descriptions

Instead of these functional requirements, the same information can be captured quite easily in ‘plain english’ descriptions of the actual business needs.

For example:

All day-to-day administration of the CMS will be conducted by the web team. There are limited technical skills in-house, so the CMS should provide easy to use GUI interfaces for administrative tasks. It is expected that the site designs are unlikely to change frequently, so the capability to maintain stylesheets and templates in-house is less important.

These descriptions are straightforward to write, and are derived directly from business needs. Best yet, they convey considerably more information in much less space, and can be ‘scored’ just as easily as a formal list of functional requirements.

In general, 4-5 pages of descriptions for your CMS requirements should encompass all but the largest of projects.

Scenarios

Scenarios provide a ‘day in the life’ description of how the content management system will work in practice. They are similar to the descriptions above, but focus on the step-by-step use of the CMS for common tasks.

Wherever possible, scenarios should be provided to complement the business requirements. Scenarios also form the basis of the vendor demonstrations, to ensure they are more than just a polished ‘sales pitch’.