Make selecting a CMS a decision without emotion and without vendor hype. Develop a set of requirements, narrow the field of candidates, organize a proof of concept and evaluate all the results to select a CMS that best fits your team.
Learner Outcomes:
- describe how to develop scripts for vendor proof of concepts
- explain how to develop a set of requirements
- show how to develop evaluation criteria and compare the system candidates
2. CMS Selection: Overview
Make selecting a CMS a decision without emotion and
without vendor hype. Develop a set of requirements,
narrow the field of candidates, organize a proof of
concept and evaluate all the results to select a CMS that
best fits your team.
• set of requirements
• scripts for vendor proof of concepts
• evaluation criteria
• compare candidates
3. Teams are People
● People are emotional and have opinions
“I saw a demonstration of product X and it looks like it would
work for us.”
“Let’s use a combination of open source tools and figure it out
as we go.”
“Our team has too much work to get involved in this!”
“Let’s each take a vendor and analyze their website
information.”
“The salesperson really knows the product and it works with
DITA.”
● Harness emotion with a process and a plan
5. Define Requirements: CLC
• Critical to all steps and moving forward
• Like/Dislike is not a requirements criteria
• Developing criteria/requirements
• Gather real details of how individuals work, apply
group context, identify inputs and outputs (current
and future)
• Define business requirements/processes
• Understand and define the content life cycle
• Compile and prepare for RFI
• Move from AS IS and prepare for TO BE
• Team collaboration, understanding and agreement
7. Requirements: High Level
• Application Server Requirements
• Security
• Support
• Ease of Use - Client Interface
• Ease of Use - Server
• Performance
• Management
• Interoperability
• Flexibility
• Built-in Applications
8. RFI Process and Evaluation
Structure: Firm and polite, define the process for
vendors to follow.
• Subset of the team
• Questions from individual vendors, shared
• How completely did the vendor respond?
• Is there enough information to evaluate?
• Are answers vague or sales-oriented?
• Compare responses, point by point
• Use a spreadsheet to score
• Quantitative evaluation first (Yes/No)
• Qualitative evaluation second (+/-)
9. Proof of Concept
Request proof-of-concept from qualified vendors.
• Not how the product works and what's cool
• There is a cost associate with a POC
• Provide technical requirements
• Application not demonstration
• Provide content ready for processing
• Requirements translated into script for vendor POC
• Scenarios for content processing
• Know how content is handled outside a CMS
before adding complexity
10. Proof of Concept: Scenarios
• Create new topic
• Derive topic
• Propagate changes across derivations
• Stage topics for new release
• Search for topics using metadata
• Create new ditamap based on existing ditamap
• Review and edit
• Publish
• Archive
• Add metadata to other objects
11. Proof of Concept: Scripts
Scenario One: Create new topic
Using the CMS and Oxygen, create a new DITA task
from scratch. Make task simple, like “Make a peanut
butter and jelly sandwich.” Include 3-5 steps. Do not add
metadata. Save the file as t_make_pbj_sandwich.xml and
demonstrate the check-in process. Upon check-in,
demonstrate how the CMS enforces the requirement to
add values for product, audience and vrm to the prolog.
Add required metadata (product=“myway”,
audience=“provider” and vrm =“8.6”).
12. Evaluating Vendor Responses
• Agenda for POC
• Scenarios are the script for vendor and for the
evaluation team
• Each person participating in the POC tracks and the
evaluates the vendor response
• Yes/No/Comments
• How well does the product functionality meet stated
requirements? Grade
• Evaluation is not a discussion
• Turn evaluations and compare results