1. Implementation and Post Implementation Student Systems at Purdue July 2, 2012 Session 118 Robert A. Kubat Purdue University University Registrar

2. Implementation Timeline Project Staffing and Work Groups Governance – Project and Post Go-Live Support/Technical Center Communications Budget Training Security Functional Central Offices Reporting and Business Intelligence Lessons Learned Continuous Improvement Discussion TOPICS

3. IMPLEMENTATION TIMELINE 2003 – OnePurdue Project 2006 – Change of vendor January 2007 – Contracts signed March 2007 – Software installed January 2008 – General Person and Student (for FA) live February 2008 – Financial Aid live August 2008 – Most Student functionality live August 2008-2009 – All functionality implemented in student life cycle September 2009 – CRM go-live

4. PROJECT STAFFING AND WORK GROUPS Project team from central IT and originally about 15 functional staff, most from core student units In addition, key staff from core units involved in work groups around functional areas throughout project – about 15 additional staff who basically had two jobs throughout project Student Systems Competency Center formed after go-live, now numbers 10 functional staff and equal number of technical staff with additional responsibilities for teaching and learning enterprise solutions Enrollment Management funded two-years for two reporting experts Work teams that combine SSCC and functional office staff continue for upgrades and bigger projects Functional offices handle all aspects (except for data feeds) for “cloud” e- bills and payments and CRM

5. GOVERNANCE STRUCTURE Champion the project across campus Communicate to other executive leaders Understand that go-live is not the end of the project, but rather the beginning of the implementation, change and continuous improvement Should not get in the weeds EXECUTIVE LEADERSHIP and SPONSORSHIP

6. STUDENT SYSTEMS OVERSIGHT COMMITTEE Makes major decisions on enterprise systems moving forward after go-live Helps secure funding if additional products are needed Assists the executive lead person Delegates authority to other groups or individuals (e.g. communications and specific functionality)

7. ADVISORY COMMITTEE (S) Represents various groups from across the university community. Options are an overall committee, use existing groups, or both: Central administrative offices Students Faculty Governance Academic Advisors Schedule and curriculum deputies Representatives of colleges and schools

8. ROLE OF ADVISORY COMMITTEE (S) Assess decisions Changes to academic and business policies, processes and procedures Recommend improvements Caution – need time to become accustomed to changes from legacy system – true improvement or just comfort with doing things the old way?

9. OPERATIONS COMMITTEE Smaller operational groups for specific areas such as registrar, bursar, admissions, financial aid Review processes after been live Schedule of upgrades and testing Schedule of improvements, service requests, schedule critical dates, cyclical major functions

10. POST GO-LIVE PRIORITIZING OF PROJECTS Membership Frequency of meetings Process and timing after go-live What criteria do you use to determine priority of projects? Sample of document used to submit projects. Do offices have the resources to complete the projects on the priority list and on time? May have to make adjustments in when projects get done due to other projects, resources such as staffing for programming and testing

11. CRITERIA FOR PRIORITIZATION Business Requirements Government or university mandate Technical directive University directive Strategic Implications Level supports university strategic plan Creates economy of scale or best practice Leverages university’s IT investment Benefits Estimated net cost savings Potential revenue generation Enhanced productivity/service Risks Extent of impact Business and/or technology risks if not implemented

12. SUPPORT CENTER FOR SYSTEMS Who is responsible for and leads the center? How many staff for each of the major functional and technical areas? Are functional and technical staff combined or separated? Responsibility for testing Responsibility for development Responsibility for project management Staffing in core business areas for liaison and work groups on major projects

13. COMMUNICATIONS Different process than communicating prior to and during implementation Provide updates on enhancements frequently Provide updates on changes as they occur Keep your communication channels open Always be honest, do not sugar coat and be upfront and direct Manage expectations; always better to under-promise and over-deliver Consult with/train change management experts – not just during go-live but for new major projects and upgrades

14. Newsletter Open forum/town halls Different messages and media for different audiences Address rumors Communicate successes no matter how small Schedule of upgrades and testing COMMUNICATIONS CONSIDERATIONS

15. BUDGET Staffing – prior, during, post Software Hardware Consulting Space One time costs vs. recurring costs In core offices – will probably need additional staff first year, then should begin to realize efficiencies

16. TRAINING Who is responsible - support center or functional offices? Appropriate documentation for end users Train end users the way you want them to learn and operate Train staff the way you want to use the system Reevaluate after go-live

17. SECURITY Who is responsible for approving access? Determine roles for specific groups How much access do you want to give? What groups should have access to which forms? FERPA,GLBA, and HIPPA certifications What changes do you need to make based on actual functionality, responsibility and process?

18. FUNCTIONAL CENTRAL OFFICES Change in business processes – not just software How will changes affect organization of staff? What may be new responsibilities for staff? What new skills will be needed by staff? Will automation eliminate staff or allow you to reassign staff and resources? Will need functional/technical staff?

19. REPORTING Should be a priority from the beginning of the project Should move along with the project Determine a reporting philosophy What data needs to be in the data warehouse? Report writers need to have knowledge of the data as well as reporting tool Work with end users to ensure their needs are being met Ask what information end users need – not what reports they want Once operational and compliance reporting in place, move toward business intelligence with today’s tools

20. LESSONS LEARNED Need a good relationship between offices and support center and need to constantly work on that relationship Stay vanilla until you have learned the system Things will be blamed on Banner that are not a result of Banner i.e. 5 digit course number Office directors must be knowledgeable and get hands dirty Some requests for enhancements went away because we were learning about the system Do not try to implement your old system!

21. LESSONS LEARNED (CONT.) Appropriate amount of time for implementation Must have knowledgeable consultants for us with large school experience Test, test and test Create good documentation Legacy system took 30 years to get where it was, give time to develop the new system to where it needs to be Change in culture takes time and attention You’re NEVER done!

22. CONTINUOUS IMPROVEMENT The rewarding outcome of a highly functioning team between IT and business offices! Stability and little downtime, even with a major upgrade Hundreds of consumer report generators across campus with over 150 validated reports in library Richer research on student success New student and graduate tab Online enrollment certification Agree to terms online Powerful CRM for recruitment and yield Paper be-gone with document imaging No lines of students at the beginning of the term! Coming up – online transcripts, degree audit, workflow, partner with vendor for improved student registration interface You’re never done!

23. Thank You and Question? July 2, 2012 Robert A. Kubat rkubat@purdue.edu