The web content management feature matrix can be a useful tool, if you use it wisely. Here's how.
Web CMS Requirements Matrix Defined
If you've ever had to evaluate a solution then you probably know what a requirements matrix is. Typically in the form of a spreadsheet, it is a list of capabilities -- or requirements -- a given product or service needs to have for you to consider it.
The capabilities are listed, usually by high level category, down the first column on the left. Across the top, you can list the various vendor solutions you are evaluating. In the middle, you start marking which requirements the solution meets, making notes if necessary.
In some cases, the requirements matrix is used as a grading tool, where a team of business and technical users vote (between say 1 and 5) on how good a vendor meets each requirement.
Sample Section of WCM Requirements Matrix
Components of a Typical Matrix
A WCM Matrix generally has a number of categories including:
- Content Entities: This area concern the root format of content in the system (i.e., is it a page or item); what content types are available out of the box and are they customizable; the ability to add new content types and metadata; how you can reuse content; how is rich media content handled etc.
- Taxonomy Features: Is there support for tagging, can you have more than one tagging/taxonomy model, is there support for categorization, etc.
- Versioning: Is content versioned, versioning structure, can you view previous versions (including side by side redlining review), revert to a previous version, is there versioning for a complete site and more.
- Workflow: Is workflow supported? What workflows come out of the box, can you create custom workflows, are there notifications/alerts, can you have parallel workflow (i.e., sending content to print and translation at the same time).
- Multilingual Support: Is there support for multiple languages, is there a default language (which is displayed if the requested language is not available), can the CMS be localized, etc.
- Editorial Features: How can content be created (WYSIWYG editor, in-content editing, MS Office), spell checker, adding images and other media to content, work queues, what browsers and mobile devices are supported, is there desktop integration?
- Social Media/Web 2.0 Integration: What Web 2.0 features are built in? Comments, tagging, user generated content, support for blogs, wikis, social networking, forums, etc.. What 3rd party vendor solutions are integrated (including widgets and/or complete solutions).
In addition to these important considerations, you also need to assess the WCM on technical points, such as the core technologies used (Java, PHP, ASP.NET), ability customize the system and presentation (availability of APIs, etc), templates and theming available and the content delivery architecture (caching models, technical architecture, etc.).
Creating Your Custom Requirements Matrix
The WCM requirements categories listed above are general -- they are not specific to any WCM nor to the needs of any particular organization. What you have to do is understand how the WCM solution you select must function in order to fit your specific requirements, and then create your own version of the matrix. This task is not easy for a couple of reasons.
First, if you are not experienced in web content management, then you are probably not the best person to to define your WCM requirements. You may have no idea if it matters if your content is created as a web page or an item. You also may not know if caching is really important or not. You'll need to find the right people to provide input.
Second, you may think you know what you need and so you create your matrix to fit those needs. However, when evaluating vendors, you learn about other ways to do things, or other things you can do with a WCM solution that aren't on your matrix.
What do you do then? Every vendor has a different pitch, which always includes what they believe are a number of differentiators. This can make your evaluation process difficult at best.
So what do you do?
The Requirements Matrix as an Internal Tool
Some would tell you to throw away the requirements matrix completely, but we don't agree. There are some good ways to use this matrix that make it a beneficial tool longer term.
The WCM Requirements Matrix is great for initial research, prior to vendor presentations. Create a base matrix based on common functionality. You can find this by looking at just about any WCM vendor website or analyst research requirements matrix. Don't build this matrix based on your requirements, this is not about your needs yet.
Take this initial matrix and start doing your own web based research on a number of WCM vendors. Be prepared to update the matrix with additional functionality as you find it (like we said, every vendor tends to be a little different). To get two very different perspectives on capabilities, have both a technical and business analyst do the research, covering the same vendors.
Note that this is not a grading process, it's research. What you get from it is a good look at WCM is all about and what functionality you can get. It should also not be a long process. Spending a couple of hours on a vendor solution should give you enough information to get started.
Build Your Functional Requirements
Start by understanding and documenting the business requirements for a website or an application. Once you have these well understood, the next step is to define the functional requirements. Functional requirements and associated use cases and scenarios outline what a website or an application needs to do. It is the detailed content or functionality that must occur on the site (or in the application).
There are many different approaches to getting functional requirements. There are also some very clear guidelines on what you should and should not do as you gather them.
One of the most important things to remember is that you are documenting what a system needs to do and not how it does it. For example, a functional requirement is that an author needs to create a content article easily. It is not that a content management system needs to be purchased. So you don’t say what needs to be done, you say what “functionality” needs to exist in the new application or site.
There are many different ways to gather requirements including:
- Focus groups
- Scenario maps
- Use cases
All of these approaches involve talking to one or more people who use the application or who own/need the website. It’s important to look for what works well and what doesn’t work well. Your job as documenter of functionality is to ask a lot of questions, be sure you understand the business processes that are performed and what the user sees as their issues or needs.
Your job is not to suggest improvements -- not during the gathering process. You listen, you learn, you document. Later you work on solutions and suggestions for improved processes and functionality.
Should Potential Vendors Get the Matrix?
No. Why not? Because some vendors will take the list of requirements and simply tick off "yes" they have them. They won't take the time to consider how the requirement is being used, or if it's really needed at all.
You also don't get a feel for how hard a vendor feature is to implement by getting back a spreadsheet with a bunch of check marks. Yes, functionality K is built-in, but you have to do x, y or z to use it like you want to..
Focus on Scenarios
You spent a lot of time of effort defining functionality, use cases and scenarios right? Those are what you should give vendors. Maybe not all of them (especially if you've defined a large number). A subset, consisting of the following should be enough to help vendors prepare demos/RFP responses for you:
- A simple use case -- what's the most basic use you will need? Some WCM products are complicated and don't allow for simple use without adding a lot of overhead. If your needs are not complicated, you need to find a solution that is not complicated.
- A complex use case -- What is one (or possibly two) of the most complicated uses you have determined? This will help the vendor determine how much customization and/or configuration may be required to make the WCM work for you.
- 4-5 Common use cases -- this should be where the bulk of your requirements come into play and where your users will spend most of their time and effort. As a result, your WCM should support these scenarios easily.
Vendors should be able to take these use cases and scenarios and explain how they would be implemented in their particular scenario. You can then see what requirements within the matrix have been used to suit your particular needs.
By combining the requirements matrix with the vendor interpretations of your scenarios, you get a feel for the WCM functionality you require and don't require. If a particular vendor solution isn't meeting much of your needs without a lot of customization or contains a lot more functionality than you require, it's easier to sit back and make a qualified decision on which solution to implement.
But It's Not A Grading Tool
What do we agree with is not using the matrix as a grading tool. Selecting a WCM vendor based on who had the highest marks is the wrong approach. How many times have you sat around the table after an evaluation trying to decide if a particular requirement is a 1 or a 3? Even the most well intentioned business or technical user is still voicing their own opinion (or the opinion of the person next to them if they don't really have one).
Getting Value From the Matrix
Using the WCM requirements matrix for initial evaluations and then using it to help create use cases or scenarios is a good use of tool that is traditionally misused in organizations.
It helps you understand what is out there for solutions and what functionality each solution contains. It's also a matrix you can keep going forward -- updating as necessary -- so that when the time comes to look at a new solution or a new version of a solution, you've already laid some of the ground work.