Creating a Change Management System from Scratch

1. Creating a Change Management System from Scratch Session Details Track 5Thursday, October 20, 20053:55 p.m. - 4:45 p.m.Meeting Room W300 Speaker(s) Laura Joyce Moriarty, Business Analyst, Emory University Session convener: Bob Gagne, CIO and Executive Director, York University

2. The University Change Management Enterprise: A Nascar Race or Eating an Elephant? Change Management is a rising issue in the world of university business and IT administration. In Educause’s Fifth Annual Survey, Question #3 asked, “Which IT-related issues are you, as an IT Leader or administrator, spending most of your time addressing? Change Management was ranked 9th in 2003, and in 2004 it moved up to position #7. Nascar or Elephant: Is it just moving too fast, or is it just too big?

3. So, is this increasing interest due to the general belief that IT is a moving target, and therefore, change must be taking up a lot of time? • Or could this perception be due to an increased array of technology things and confusion in choices, costs, benefits, and unrelenting discussions that you suspect may be more about resistance than change? • Maybe it is due to higher education’s wild reputation for embracing unwieldy innovation and cutting edge technology?

4. If you understand the size and pace of change in your infrastructure, neither the speed nor the bigness of these many-changing things will top your priorities when thinking about managing the changes. • The real confusion won’t start until you have to deal with the more amorphous mental meanderings of your technical staff and business owners who also have their own vision of what Change Management constitutes. • For example, the first question you might hear from you colleagues is, “What is a Change?”

5. The Tradition of Change Management • When the mainframe reigned supreme, Change Management requirements were directed to a very narrowly defined set of systems and application processes. • A typical university’s so-called Change Management system usually consisted of the following disconnected components: • a weekly meeting of interested or affected parties, who usually discussed all the previous week’s unadvertised, unauthorized, or otherwise, unaccountable changes that caused distress across the campus. • {Note: Of most gruesome contemplations were the unplanned events that brought down a system during student registration or final exams.}

6. a set of policies, used infrequently, as most of the processes used in these similarly constructed systems were very redundant. • an e-mail filled with boiler plate to-dos or standardized instructions for the operators. • a reply e-mail that confirmed changes were completed— without a back-end tracking or accountable application mechanism. • The distributed computing infrastructure of today’s varied IT technical units, systems, emerging projects, and campus wide interdependencies resembles a chaotic universe of images; a picture that is vastly different from the legacy landscape.

7. Settling on a beginning and an end can become very stressful, and why something that might seem obvious at first glance is, in fact, filled with illusive and multifaceted objects of discussion within the university business and IT infrastructure. • Thank goodness for us all, however, there are “auditors.” • And IT auditors have very strong opinions about what constitutes an IT change and when that change begins. • They come armed with much legacy experience and golden mainframe times gone by.