The University of Massachusetts A Multi-campus ERP Implementation

The University of Massachusetts A Multi-campus ERP Implementation Case Study: What Worked and What didn't Robert Solis Director, Information Technology Services March 17 th, 2003 – 8 am, Meeting Room A NERCOMP 2003 Conference – Worcester, MA. 1

Copyright Robert Solis, 2003 – University of Massachusetts. This work is the intellectual property of the author. Permission is granted for this material to be shared for non-commercial, educational purposes, provided that this copyright statement appears on the reproduced materials and notice is given that the copying is by permission of the author. To disseminate otherwise or to republish requires written permission from the author. 2

Themes for the Day • • • Chapter 1 - The Beginning Chapter 2 - Transition/Collaboration Chapter 3 - Staffing the Project Chapter 4 - Project Structure and Governance Chapter 5 - Project Execution Chapter 6 - Go Live and Preparing for Operations 3

Chapter 1 – The Beginning 4

The Beginning • Some quick facts about UMASS– Established in 1863 in Amherst – More than 70, 000 students enrolled in undergraduate, graduate and continuing studies programs – 22, 000 employees – Annual payroll of $806 million ($31 million/pay period) – FY ’ 03 operating budget of $1. 3 billion s pu am 5 C he ice – & t Off 03 s 20 stem t’ en d Sy id es an Pr th ou d rtm she Da bli S- sta AS ll E UM we – Lo 91 S 19 AS UM n sto Bo Sr AS ste UM ce – ed or W 54 ish S 19 tabl AS Es UM t – ed 52 lish st e hers 19 er tab leg m Es Amh Col S-A S – ral A 47 ltu UM 19 ricu es Ag com be rst ge he olle Am C – ral 63 ltu d 18 ricu ishe Ag tabl Es 5

The Beginning • UMASS Consists of 5 campuses (Amherst, Boston, Dartmouth, Lowell and Worcester) and the President’s Office Amherst Lowell President’s Office Boston Worcester Dartmouth 6

The Beginning – Each campus and the President’s Office had their own HRMS/Financials mainframe applications Lowell Amherst President’s Office Boston Worcester Dartmouth 7

The Beginning Interfaces • Because the 5 campus/President’s Office UMASS system was in it’s infancy in the 90’s, 3 autonomous People. Soft Projects had started (and stopped)… – Each had their own project team, governance model, database, requirements, modifications, consultants, budgets and timelines – However, each had to meet the same Board of Trustees requirements and interface with the President’s Office Amherst (Project Pioneer) Boston and Lowell Dartmouth, President’s Office, Worcester • Started in 1999 • Started in 2000 Board of Trustees Requirements 8 Looks like silos to me (trying to accomplish the same thing)…

The Beginning Then someone had an idea in the new millennium… Why not consolidate projects? Oh @#$%! 9

Chapter 2 – Transition/Collaboration 10

Transition/Collaboration The Transition Phase (May 2000 – July 2000): “The Summer Summit” – Campus/President’s Office subject matter experts convened to: 1. Agree on project logistics, staffing and governance 2. Develop consolidated implementation work plan 3. Identify and prioritize application modifications, interfaces and reports 4. Jointly design business processes 11

Transition/Collaboration A typical Transition Phase working session Boston and Lowell have been talking and we’ve decided… My campus can’t live without this report… Why do we always have to do what Amherst wants? This is ridiculous, I’m outta here! Better run that by the President’s Office… What you propose is in violation of Trustee policy… 12

Transition/Collaboration • Drivers for Consolidation vs. Separation – Standardization of university business processes – Increased coordination/communication between campuses/President’s Office • Formal and informal knowledge transfer networks – One university application – Resulting in: • Shared implementation costs • Shared maintenance costs • Shared technology infrastructure 13

What worked… • Creating an immediate inventory of consolidation ‘topics’ to be tackled • Agreeing quickly on the ‘summit’ participants • Making the commitment to focus on the transition phase • Centralization of the project office; dedicated work space to accommodate each work group 14

What didn't… • Deliberation on EVERY issue, not always tailored to the net impact of the issue • Not nearly enough time developing the work plan / project framework for the upcoming project 15

Chapter 3 – Staffing the Project 16

Internal Staffing • Defining roles – What role would the campus and IT play – Applications/module teams created – Team leads assigned • Functional/Business resources – Filled by campus central admin staff (HR and Finance) • Technology resources – Created a central IT organization to manage the project and assume operational responsibility at go-live 17

Consulting Staffing • Selecting an implementation partner was a joint decision by the campus leadership • Chose to ‘partner’ by segmenting the work 50/50 – UMass to Consulting • Used management, applications and technical consulting in order to learn for future projects 18

What worked… • Solid commitment for business knowledgeable project resources at each campus • Each campus offered some level of ‘incentive’ for travel to the central project site • Buy in from leadership and project team on: – Project location – Expected time commitment to the project – Who filled what role • Good knowledge transfer from the consulting staff 19

What didn't… • Project resources and the communication to leadership back at the campus • ‘End users’ not involved at the right level • Filled internal staff positions late in the process (hiring of PS expertise) • Multiple consulting partners relationship was complex and ‘clumsy’ at times 20

Chapter 4 – Project Structure and Governance 21

Project Structure and Governance 22

Project Structure and Governance 23

Project Structure and Governance Enter the Governance Model… Characteristics of the Governance Model • Designed for decisions to made at the appropriate project “level” • Issue resolution/escalation process prevents items from being “tabled” • Equal representation at all levels for each campus/President’s Office • Clearly defined roles and responsibilities 24

Project Structure and Governance Culture Changes As a Result of the Governance Model 1. The old attitude of “that is unacceptable with my campus” became “I’d like to run that by the module team and see what everyone thinks” 2. Application modifications were seriously questioned as to their necessity 3. System wide considerations were placed above campus considerations 25

Project Structure and Governance The Governance Model 26

Project Structure and Governance Issue Resolution/Escalation Process Module Team Issue/Decision Work to Resolve Issue/Decision Module Steward Module Team Develop Consensus Yes Issue/Decision Resolved No Decide on Issue/Decision Yes Application Cabinet Refer to Application Cabinet Review and Decide on Issue/Decision No Application Steward Application Cabinet Develop Consensus No No Decide on Issue Yes Close Issue Close Yes Review Decision with Application Steward Issue/Decision Resolved Document Resolution Module Team 27 END Refer to Design Phase or Integ. Cabinet

Project Structure and Governance Putting it all together…The Governance Model 28

Project Structure and Governance Superimposed with the…Project Management Organization 29

Project Structure and Governance Bring in the Project Organization Model… 30

Project Structure and Governance Now add some clear decision-making process flows… 31

Project Structure and Governance And bring in your implementation partners…viola! $ 32

What worked… • Cross campus collaboration and sharing of ideas was invaluable (and continues to be so) • Decision making at the project and executive level effective • Effective tracking of issues throughout 33

What didn't… • Tendency for everyone to want to be involved with everything • At time practice of governance not true to model • Reliance on the strongest resources created unbalanced workloads for some 34

Chapter 5 – Project Execution 35

Project Execution • Phases spanning 2+ years of work – Application and infrastructure • • Configuration Design Build and Test Deploy 36

Project Execution KEY = 37

What worked… • Communication – List serves established (different e-mail systems) – Status reporting for key audiences • Strong testing effort and documentation • Effective modification approval process • Solid change control tracking 38

What didn't… • Communication – Sometimes not timely – Better tailoring of focus needed for the audience • Meetings – Perception of too many meetings – Many meetings too long in duration • Not enough time spent understanding each phase prior to starting that phase 39

What didn't… • Better/more end to end testing • Need to focus on performance testing MUCH earlier • Map out database instance definitions earlier 40

Chapter 6 – Go-Live and Preparing for Operations 41

Go-Live • Go live readiness – Developed a detailed go live readiness criteria list with go/no go decision scoring for each criteria – Held readiness meetings with 5 different key constituency groups at 3 different intervals prior to golive • • • Project office Project management team Core project teams Campus leadership teams Applications Cabinet teams 42

Preparing for Operations • Developed operations processes concurrent with go live planning and execution • Utilized Sr. Project Manager to organize required operations processes (‘run book’) • Established teams of cross IT groups to develop and test required processes 43

What worked… • Go live preparation and execution • Campus readiness, preparation and participation • Post go live support structure and commitment – ‘Command Central’ • Tiered support structure – Tier I – Campus help desk – Tier II – Campus application experts – Tier III – Central IT group 44

What didn't… • Definition of end user applications expectations not done early • Applications operations and support processes developed far too late (should have started prior to go live prep and rollout) • Remember transition/collaboration 2 nd bullet: Not nearly enough time developing the work plan / project framework for the upcoming project 45

End Product A consolidated HRMS/Financials Application and shared technology infrastructure A path to a competitive future Amherst Lowell President’s Office Boston Worcester Dartmouth 46

Key takeaways from this session • Spend time up front: – Building your team – Building a governance model – Developing project methodologies – Developing an issues management process • Keep an operational focus (early on) • Define communication protocols, formal and informal • Focus early on expectations management • Get buy in from as many levels of constituencies as possible 47

Questions: Robert Solis, Director, Information Technology Services University of Massachusetts 508 -856 -3362 robert. solis@umassmed. edu 48