Scenarios are narrative descriptions or stories that concisely outline how something will work in practice.

In the context of a content management system (CMS) project, scenarios are a very effective way of documenting key CMS requirements, and they complement the formal lists of functional requirements typically found in tender documents.

Content management scenarios provide a ‘day in the life’ description of how the CMS will be used, for example:

Richard enters the text for the page, and creates a link to the supporting PDF. Once the content has been spell-checked, Richard submits the page for review by Jane, his manager.

By using this story format, a large number of details can be conveyed in relatively few words. In practice, a single scenario can cover the same scope as several pages of functional requirements.

Scenarios are most effectively used during vendor demonstrations, to provide a ‘script’ for vendors to follow. This ensures that the vendor shows how the product will work in practice, meeting the specific needs of the organisation.

Having a common script across vendor demos also makes it easier to compare solutions, as well as providing a strong foundation for scoring the products against functional requirements.

This article will outline how to create effective scenarios, including concrete examples, guidelines and suggestions.

Use scenarios as a ‘script’ for vendor demonstrations

Role of scenarios

Scenarios play a number of important roles in the CMS selection process:

• Capturing key business requirements
  Scenarios are an effective and succinct way of exploring and documenting key business requirements for a CMS.
• Clarifying issues
  When requirements are written in a narrative format, any gaps, errors, or areas of uncertainty become very clear. Ensuring that the scenarios are fully understood helps resolve any issues before the tender is conducted.
• Making abstract requirements concrete
  Focusing on specific activities and tasks makes the functional requirements concrete, and places them in the context of broader business processes.
• Allowing internal review
  By documenting the requirements in a simple and easy-to-read format, scenarios help internal stakeholders contribute meaningfully to the project.
• Enriching the tender documents
  By providing additional narrative details, the scenarios help to clarify the functional and technical requirements contained within the tender.
• Forming the basis for vendor demonstrations
  Using the scenarios as the ‘script’ for vendor demonstrations ensures that they aren’t just a polished ‘sales spiel’. It allows the demos to be directly compared, as well as giving a basis for quantitative scoring of each product’s capabilities.

Sample scenario: creating content

Robert is an author who is responsible for maintaining some sections of the website.

A new press release needs to be created for the site. Robert creates a new page in the CMS, indicating that it will be a press release. This provides a number of specific fields to be filled in (such as title, release date and contact details for the press officer), as well as an area for the body of the press release (as formatted text).

The material for the press release is cut-and-pasted from a Word document, and the CMS automatically cleans up the content to match the standard website appearance.

Robert then creates a link within the press release to another area of the site, as well as to an external agency website. An image is selected out of the image repository within the CMS, and placed in the top right corner of the press release.

As a final editing step, he spell-checks the page to ensure there are no mistakes.

Robert then specifies the metadata for the page, which has been made very simple by the CMS (many of the values have been defaulted or pre-filled). He also indicates that the press release should be released at 9am tomorrow morning, when the press release will go to the media.

Having completed the draft press release, Robert forwards it to his manager Lyn for her review. Lyn is notified via email that there is a page to be reviewed, and clicks on the link in the email to go directly to the relevant workflow task.

Lyn checks over the draft press release. She is happy with the content, and so forwards it to Sandra (one of the web team) to do a final quality check, before approving it for release.

Once live, the website will automatically add a brief summary of the release to the main ‘press releases’ page.

Creating scenarios

Scenarios should be created as a standard part of the CMS selection process, either in parallel with or after the creation of the requirements document.

The scenarios can then be packaged up as part of the overall tender (RFP) package, and provided to vendors. If time is tight, the scenarios can always be provided only to the short-listed vendors, giving the project team a few more weeks to get the scenarios finalised.

Scenarios should not be hard to write. Taking a straightforward ‘narrative’ approach means that verbal descriptions of the way it should work can be transcribed directly into scenarios.

Once draft scenarios are written they should be circulated to key stakeholders in the organisation. This ensures that consensus is gained on how the CMS should work, as well as giving an opportunity for issues to be identified and resolved.

To help in the scenario-writing process, the following sections contain a number of guidelines and suggestions drawn from real-world project experience.

Number and length of scenarios

While scenarios are very useful, they must not be unmanageably long. Most vendor demonstrations should run for 2-3 hours (any longer and the endurance of all involved will be sorely tested). That will provide time for approximately 4-6 scenarios, depending on the length and complexity of each.

It will not be possible to cover all the functional requirements listed for the CMS. Instead, the scenarios should focus on the key areas that can be best shown in a vendor demonstration.

Scenarios are for actions

Scenarios work best when they demonstrate the system in motion. That is, steps where the user interacts directly with the CMS, and the system responds. Scenarios are not so effective for exploring individual features or functions of the system.

For example, a scenario could very effectively focus on ‘creating a press release, and linking from it to existing web pages’, but would not be appropriate for ‘integration with existing XML data sources’. The former consists of a series of actions by the user, while the latter is a detailed programming aspect of the system that is set up in a configuration file.

Concentrate on common tasks

There will be a small number of tasks that will be done repeatedly by users of the content management system. The usability and efficiency of these specific tasks will have a large impact on the overall viability of the product.

For this reason, the scenarios should focus on some of the most common tasks conducted in the CMS.

Common CMS tasks must be easy and efficient

Don’t duplicate functional requirements

Your tender will contain a fairly long list of business and functional requirements for a CMS; your scenarios should not duplicate these.

You will not cover all CMS capabilities within the scenarios, and you should avoid creating scenarios that are effectively just a list of requirements.

Be specific

The scenarios must be more than just a high-level, generic description of the CMS (‘Joe creates a page and publishes it to the site’). For example, if you are looking to use a thesaurus with the CMS, specify exactly how you would like the user to be able to use it, beyond just a simple statement of ‘Bill uses the thesaurus to specify index terms’.

You may need to do further research into how content management systems operate in key areas, or explore in more detail the needs of your stakeholders. You may also wish to discuss specific areas with CMS specialists to gain additional marketplace knowledge.

Focus on tricky areas

There will be a number of areas that will be hard to describe in the scenarios, often relating to advanced or ‘leading edge’ requirements. While the temptation may be to gloss over these details in the scenarios, you should do the opposite and focus on these difficult areas.

If you don’t have a clear idea of how these aspects will work, you won’t be able to meaningfully evaluate them during the demonstrations. More importantly, any lack of clarity will strongly affect the project when it comes to actually implementing the system.

If you can’t clearly articulate a need, seek further assistance (we can probably help out). If the need is still not fully understood, question whether it should be included in the tender.

Don’t include implementation details

Implementation details should not be included in the documented scenarios, as these will restrict how the content management systems can be evaluated (a product may provide the desired capability, but not in the same form as other systems).

An example of a scenario that includes implementation details:

Peter opens up the list of available templates, and selects one from the list. This presents a dialog box asking him to pick a suitable workflow associated with his team. If a new template needs to be created, Peter can click on the button at the bottom of the initial screen to open up the Template Creator.

While this example contains considerable detail, it actually doesn’t convey much information about the task that Peter is trying to complete. Instead, it focuses on many low-level details about the CMS, such as templates.

Including this type of implementation details will also give the prospective vendors the impression that you have a pre-selected winner in mind, or that you just want to replicate your current solution.

A good way to avoid including implementation details is therefore to not use any jargon or technical terms in the scenarios.

Avoid just describing how your current product works

Find a balance between the present and future

When writing scenarios, avoid two extremes:

• Scenarios that reflect exactly how things work at present, including the historical baggage and legacy aspects that have built up over time. This prevents the CMS from updating and improving the way the organisation operates.
• Scenarios that are a ‘wish list’ of advanced features, many of which would be very difficult to implement in the context of the current organisation (trying to run before you can walk).

In between these two options is a balance where the scenarios reflect the current realities within the organisation, while still allowing practices to be revised and improved.

Ensure vendors follow the scenarios

The scenarios will only deliver the desired benefits if vendors follow them when conducting their demonstrations.

Vendors should therefore be given very clear instructions as part of their standard invitation letter, along the lines of:

The vendor demonstrations are a key component of our evaluation process, and we strongly encourage you to follow the scenarios as closely as possible. These scenarios reflect the key selection criteria for the CMS, and indicate the most important aspects of the project.

In particular, we are looking for all details in the scenarios to be clearly demonstrated during the session. Vendors who fail to conform to the scenarios may be scored poorly, or excluded entirely from further evaluation.

Where appropriate, details such as the users listed in the scenarios should be configured in advance. This will ensure that we are able to see the product following the specific activities in the scenarios.

This should be reinforced verbally with vendors if required, to ensure a high level of compliance. This allows any vendors who fail to prepare appropriately to be eliminated from the selection process.

Conclusion

Scenarios are an effective way of ensuring that a new content management system will work as required and expected.

By providing ‘day in the life’ descriptions of how the product needs to work, scenarios give the vendors clear scripts to follow during the vendor demonstrations.

The process of writing clear scenarios also helps to clarify uncertain areas, and ensure that all stakeholders have the same understanding of the CMS requirements.