Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Rfp to launch

504 views

Published on

  • Be the first to comment

Rfp to launch

  1. 1. HighEdWeb MichiganA New Content Management System:From RFP to Launch in 12 Months
  2. 2. Your SpeakersHolly LaRose-Roenicke,Assistant DirectorWeb CommunicationsAaron Maturen,ProgrammerWeb Technologies (ITS)Jason Swackhamer,DirectorWeb Communications
  3. 3. About SVSU• Enrollment: 10,500+– UG: 8,700+– Grad: 1,200+• 77% full-time students• 70% under 25• 70% of incoming freshmanlive on campus• Alumni: 38,000+• Regional institution withsome out state andinternational students• Founded in 1963(50th Anniversary)
  4. 4. Our OrganizationPresidentAcademic AffairsAdministration &Business AffairsITSWebProgrammingTraining TeamEnrollmentManagementWebCommunicationsStudent Affairs Public Affairs
  5. 5. First . . . A little history• Began decentralizedWeb management in1994• Typo 3 was second CMSsystem since 1994– Complicated to manage– Lack of consistency andaccountability– Dependence on IT forproviding functionality• CMS compromisedSuperbowl Sunday,2011
  6. 6. Pre-RFP Situation Analysis• Programming staff— number and % of time• Budget— open source isn’t free— making the case for $$• Users— who will be using daily• Workflow— levels of users, approversKey Factors in Needs Assessment
  7. 7. Web MaintenanceWeb CommunicationsManages oversight of website as awhole; sets website standards;Advises departments on social mediastrategy;Implements and trains editors oncontent management system.ITWeb Programming supportsUniversity departments throughcustomized-programming requests;Networking supports theinfrastructure to support thenetwork and serversContent EditorsReviews content with ownersannually, acts as departmentgatekeeper;Ensures pages meet the University’sstandards in terms of design andbest practice;Attends Terminal Four training.University CommunicationsSets graphic standards and messagethemes for University.Provides images in centralizedrepository
  8. 8. Needs Assessmentaka, What Does the CMS Need To Do? Enterprise System— higher ed customers Decoupled publishing— so we won’t loose livecontent again!Easy to Use— Almost as easy as MS Word Easy to Create Templates— flexible, easy for developers
  9. 9. The RFP• A COMPLEX MONSTER— 162 attributesquestionnaire, 19 pgs!• Targeted Vendors— enterprise, higher ed• Purchasing Led— managed communication• Time— gave a month forresponse due to complexity
  10. 10. Selection ProcessRFP Sent to 15VendorsRFP Responses Due30 days later5 RespondedRFPs Scored andRanked based on119 criteria, priceCross-CampusCommittee:Demos from 3,selects TerminalFourCross Campus Committee: low, mid and high level webeditors, web programming, web communications,training
  11. 11. Project PlanningDecisions, Decisions• Design (templates, CSS)• Sitemap• Migration Planning–All at once or phased?–Who does it?• Launch (how, timing)
  12. 12. Evaluate Current WebsitePlanning for Migration (Typo3 to T4) 6,102 Pages Find patterns for categorizing content Create rules for finding content toimport into templates Never logged in to Typo3 back end
  13. 13. Set up new EnvironmentTerminal Four (T4) Create new templates for migratingcontent into Port over CSS and page styles
  14. 14. Transform HierarchyBuild New Site Structure Used excel to define the new structurefor the hierarchy Used python to create the pages in newCMS and keep a reference of where theywere in old CMSTip: Use this as opportunity to fix sitestructure (nested sites)
  15. 15. Content MigrationImport Content Army of minions Created an applicationbased on the newhierarchy to assign pageswith links to old page andnew page Web crawler usingpython and a hierarchy Automatically importedabout 3,100 pages…
  16. 16. Media Asset Migration Media had to initiallybe imported by aminion into T4 All of the links toimages, PDFs, andfiles had to berelinked manuallyTip: All media will needto be imported andlinked.
  17. 17. Quality Control Minions wereresponsible for checkingtheir assigned pages Web Communicationsalso spot checked pagesTip: Have content owners checktheir content and website beforelaunch
  18. 18. Training for Admins“Train the Trainer”• Training fromvendor• Training done on“training accounts”,not live sites• Began convertingour own websites
  19. 19. Content Editor TrainingRequired for Login• Login access given at end of training- no exceptions• Conducted using “training accounts”,not live sites• Conducted (25) 90-minute trainingsin 6 months, training 145 people• Any changes made to live sitesbetween conversion and trainingwere done by minions, but fromtraining to launch were theirresponsibility to update
  20. 20. Tips To Training Success• Holding back login access• Encourage users from samedepartment to go together• Improved documentation –ask vendors to see if theyhave documentation to buildfrom• Empower users with choicesand tools to improve websites• Continuous help “T4Tuesdays”
  21. 21. Redefining RolesWeb Communications (Content)• Meet with every department annually– Review content for accuracy– Set goals/ priorities– Review analytics– Provide “report card”• Assist Content Editors• Provide training• Administer access rights
  22. 22. Redefining RolesWeb Technologies (Programming)• Administer template improvements and technicalaspects of CMS support• New process for project requests– New content templates– Forms– Special programming• Clearinghouse for all online forms• Cross training within department
  23. 23. Lessons LearnedHave a Communications Plan• Set expectations• Squelch the rumors• Communicate process,timing• Consider a content freeze
  24. 24. Lesson LearnedConduct a Crisis Plan• Brainstorm worst-case scenarios andsolutions Search broken Links to all media files broken Server space maxing out
  25. 25. Lessons LearnedKnow URL StructureTip: Try not to change it!• Legacy Links arepersistent— Scheduled Emails— Google— Bookmarks• At minimum, have agreat 404 page
  26. 26. Lessons LearnedAnticipate What’ll Break (Forms)• Some forms were processed by old CMS These broke• Some were “included” with php on page These broke• Some were external links Worked!Tip: Include forms in migration schedule
  27. 27. Lessons LearnedTriple-Check Server Setup If you don’t want a phone callat 4 a.m., make sure that thereis enough space on yourserver for the website.
  28. 28. Lessons LearnedIn Summary: 3 Key Takeaways Even though we moved fast, there weretimes that could have moved even fasterbecause in the end, we needed three moremonths Search engines take time to crawl Each site should have been reviewed andsigned off for accuracy by editors during thetraining process
  29. 29. 12 Months- RFP to Launch- Selection- Editor TrainingRFP Responses Due!Vendor Notified-Project Planning, Install,-Development- Content Migration- Quality ReviewOCT NOV DEC JAN FEB MAR APR MAY JUNE JULY AUG- Selection- Editor TrainingRFP Responses Due!Vendor Notified-Project Planning, Install,-Development- Content Migration- Quality ReviewSEPT OCT NOV DEC JAN FEB MAR APR MAY JUNE JULY AUGSelectionEditor TrainingRFP Responses Due!Vendor NotifiedProject Planning, Install,DevelopmentContent Migration- Quality ReviewLaunch!
  30. 30. Lessons LearnedIn Summary: 3 Key Takeaways Even though we moved fast, there weretimes that could have moved even fasterbecause in the end, we needed three moremonths Search engines take time to crawl Each site should have been reviewed andsigned off for accuracy by editors during thetraining process
  31. 31. Questions, Comments, DiscussionHolly LaRose-Roenicke,Assistant DirectorWeb Communicationshmlarose@svsu.eduAaron Maturen,ProgrammerWeb Technologies (ITS)atmature@svsu.eduJason Swackhamer,DirectorWeb Communicationsjjswack1@svsu.edu@jswackySlides available via Tweet Deck:

×