No Drama: Selecting the Right CMS for You


Published on

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

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

No Drama: Selecting the Right CMS for You

  1. 1. No DramaSelecting the Right CMS Mollye Barrett Leigh White
  2. 2. CMS Selection: OverviewMake selecting a CMS a decision without emotion andwithout vendor hype. Develop a set of requirements,narrow the field of candidates, organize a proof ofconcept and evaluate all the results to select a CMS thatbest fits your team.• set of requirements• scripts for vendor proof of concepts• evaluation criteria• compare candidates
  3. 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
  4. 4. Define Requirements: CLC
  5. 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
  6. 6. Content Life Cycle
  7. 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. 8. RFI Process and EvaluationStructure: Firm and polite, define the process forvendors 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. 9. Proof of ConceptRequest proof-of-concept from qualified vendors.• Not how the product works and whats 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. 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. 11. Proof of Concept: ScriptsScenario One: Create new topicUsing the CMS and Oxygen, create a new DITA taskfrom scratch. Make task simple, like “Make a peanutbutter and jelly sandwich.” Include 3-5 steps. Do not addmetadata. Save the file as t_make_pbj_sandwich.xml anddemonstrate the check-in process. Upon check-in,demonstrate how the CMS enforces the requirement toadd values for product, audience and vrm to the prolog.Add required metadata (product=“myway”,audience=“provider” and vrm =“8.6”).
  12. 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
  13. 13. Questions?Thank you!Mollye Barrett Leigh WhiteClearPath, LLC ElementalSource,