Texas State University

1. Bye, Bye Blackboard

2. Texas State University The largest university in the Texas State University System and the sixth largest university in Texas serving over 29,000 students on a 457-acre campus located in the scenic Texas Hill Country between Austin and San Antonio.

3. Presenters • Michael Farris Project lead mf03@txstate.edu • Jeff Snider DBA/Developer js38@txstate.edu • Whitten Smart User Support and Documentation ws15@txstate.edu

4. Blackboard • Adopted in 1999  • Heavily modified and aging by 2004  • Complete rewrite of the custom code required for deploying newer version • The same rewrite required for future releases

5. The Goal Provide a learning management system that: • Placed control in the hands of the people who use it, Texas State faculty. • Supported the development and maintenance of customization with minimal restrictions.

6. The Project To deactivate the customized version of Blackboard by facilitating a voluntary migration of faculty to a more robust, agile learning management environment.

7. The Project Team Michael Farris – Project lead mf03@txstate.edu Rori Sheffield – Project Assistant/User Support rp41@txstate.edu Salwa Khan – SAKAI liaison/User Involvement sk16@txstate.edu Jeff Snider – DBA/Developer js38@txstate.edu Amy Boyd – Developer/Programmer ab46@txstate.edu Sean McMains – Software Architect and Advisor seanmctex@txstate.edu Yuanhua Qu – Developer/Programmer yq12@txstate.edu James Buratti – Web Support jb63@txstate.edu Jimmy Rico – User Support and Documentation sr03@txstate.edu Whitten Smart – User Support and Documentation ws15@txstate.edu Mary Cauble – Project & Change Management mc01@txstate.edu Laura Trial – Graphic Design lt20@txstate.edu Deborah Morton – Faculty Representative dbmor10@txstate.edu Hideo Goto – Quality Assurance

8. The Beginning • Interview faculty • I like • I don’t like • I want • Document requirements • Complete gap analysis

9. Critical Success Factors • Voluntary migration • Blackboard imports • Freely modifiable code • Faculty perception

10. Blackboard Operations and Maintenance Discontinuance End of Life (1) Early Deployment and Transition Planning (3) Detailed Discontinuance Planning (2) Initial deployment to users Concept Study Pilot Final Operations and Maintenance Sakai Open Sakai enhancement releases Migration Control Gates Migration Process

11. Project Paths

12. Team Coordination • Team meetings • Redirect the Bullet retreats • Ticket system • Project site

13. OverviewThe Pilot • Fall 2005 • Membership • 10 faculty, +/- 900 students • Spring 2006/Summer 2006 • Membership • 25 faculty, +/- 2000 students • Criteria for faculty selection • Sites in Blackboard, extensiveness of Blackboard site, computer use • Support • Hand holding • Survey • Results and Lessons Learned

14. GoalsThe Pilot • Recruit 1,000 users • Develop initial branding • Develop strategy for features • Create demand for TRACS • Create proactive support structure • Create effective training • Develop Blackboard, TRACS inter-application interface • Be ready for faculty

15. Change ManagementThe Pilot • Executive Support • Provost • Vice Presidents • Assistant VP • Deans • Faculty • Chairs • Faculty Senate • Focus groups • Liaisons

16. SupportThe Pilot • Fall 2005 • Handholding • One on one faculty training • In class training • Documentation • Phone and e-mail

17. SupportThe Pilot • Spring 2006 • Workshops • Beginning • Advanced • Gradebook and Assessments • TRACSfacts • OTRS

18. InfrastructureThe Pilot Pilot system • Virtual, since we didn’t know what we needed What worked • Apache &mod_jk • Multiple app servers What didn’t work • Files stored in DB • So few app servers (They die a lot)

19. Lessons LearnedThe Pilot • What We Did Well • Identified and selected pilot faculty • Created TRACSfacts • Paid attention to branding and user interface • Had faculty recruit colleagues for next semester

20. Lessons LearnedThe Pilot • What We Needed to Do Better • Remember, the user is not us • Acknowledge the dark side and do the opposite • Revise and prioritize relentlessly • Be gracious, be humble, be honest and be authentic • Communicate directly with students • Go slow, stay low, keep moving, and don’t get too greedy

21. OverviewThe Migration Begins

22. OverviewThe Migration Begins • BB archive import • Curriculum for workshops and documentation • Faculty readiness survey

23. TRACS Readiness SurveyThe Migration Begins

24. InfrastructureThe Migration Begins • Open Migration System • What changed • Real hardware • Several instances of the app per server • Separate storage for files • What didn’t work • Cheap network switches that failed under load gave us a big black eye at the start of semester

25. OverviewThe Middle Years Course Sites in TRACS

26. OverviewThe Middle Years • Spring 2007 through Spring 2008 • Focused on reliability • Proactive in Sakai community • Expanded support efforts • Involved faculty in core team • Determined end date of Blackboard

27. Change ManagementThe Middle Years • Message of the day • Faculty Steering Committee • Individual visits with the chairs • New faculty • Dean, Chair, Faculty, Student and TA messages • Published Blackboard end date • Who’s in BB, who’s in TRACS, who’s in BB and TRACS, and different communication for each

28. SupportThe Middle Years • Workshops • Training videos • TRACSfacts re-vamp • Faculty to faculty help • FAQ

29. SupportThe Middle Years

30. Support The Middle Years • Steering Committee • Role • Criteria • Support • Expectations

31. InfrastructureThe Middle Years • By Spring 08, average daily sessions had risen from 700 to 2500. • Added another server capable of running four more instances of the app • DB server load is consistently high, so we submit a request for a new server

32. Lessons LearnedThe Middle Years • What We Did Well • Communicate, communicate, communicate • Offer training in every conceivable format • Steering Committee recommended end-date • Added a faculty member to the project team • What We Needed to Do Better • No changes, no matter how “inconsequential,” right before finals • It’s the Faculty Steering Committee • Acknowledge the obvious

33. The Final Days

34. OverviewThe Final Days • Summer 2008 • Focus on last 5% of faculty in BB • Focus on staff project sites • Utilize targeted communications • Carryout progressive dates of BB shutdown

35. Change ManagementThe Final Days • Returned to handholding • Made telephone calls • Changed BB login page numerous times • Scheduled office visits • Insured administration awareness • Contacted project site owners

36. Support The Final Days • Increase support staff • Conduct fewer workshops • Create more videos • Implement Bomgar • Improve coordination with campus helpdesk • Deploy new telephone system

37. SupportThe Final Days

38. Lessons LearnedThe Final Days • What We Did Well • Use multiple methods, avenues of communication • Track the stragglers • What We Needed to Do Better • Test, test, test • No changes, no matter how “inconsequential,” at the beginning of the semester • Remember the students • You can’t please everyone • Remember the non-traditional courses

39. InfrastructurePull the Plug • New DB server finally comes in. One day before the start of Fall. • Old DB server is overworked. • We tried to wait until a weekend to upgrade -- Mid-week upgrade decided for us. • New DB server is huge. Tuned for speed. MySQL allocated 12Gb.

40. Pull the Plug • Build a better system and they will come. • Take the extra steps and time.

41. OverviewInto the Future • Define archive retention process • Stabilize release cycles • Increase involvement of Steering Committee • Focus on pedagogy • Deploy a knowledge base • Improve QA test process • Create task-based help

42. InfrastructureInto the Future • Increase file space • Big appetite for storage • Several gigs per day • Multiple Load Balancers • One is fine, until an app blows up • More redundancy • More RAM for app instances • Ideally 5+ Gb each

43. Q&A