Change Management

Administrative Information Services

Change Management Project

Phase 1: Requirements Analysis

Authored By: Mike Belinc, Enterprise Systems Architect Date: December 20, 2005

2

Project Acknowledgements

Many people contributed to this project and should be recognized for their efforts. In addition to the project team, interviewees included a cross-section of management and staff. Contributors are listed accordingly.

Project Leader

Mike Belinc

Project Team

Jeff BleamPeter deVriesRich DummGary GentzelDarryl GriffinKelly HartzfeldEd HayesClyde LeFevreEd MicucciAaron MorrisonRick RhoadesCarl SeyboldRusty SodergrenSteve StricklerCharlotte Wilusz

Project Volunteers

Mike KauffmanTodd LitzingerKen Schroyer

Project Interviewees (AIS Management Team—Not on Project Team)

Scott SmithPete DawsonKaren SchultzDawn BoyerDenny MorrisonMarta Miguel

3

Project Interviewees (Project Team Candidates—Not on Project Team)

Pam DownsYvonne RileyBrian FranceEric HelfenAaron HofeltDiane WellerDave Hoover (1) Scott NeidighShelly GetteGreg Von Kuster Bill Cook

(1) Dave was selected but later replaced due to change in jobs.

4

Table of Contents

PROJECT ACKNOWLEDGEMENTS...........................................................................2

EXECUTIVE SUMMARY...............................................................................................6

PROJECT BACKGROUND............................................................................................8

PROJECT OBJECTIVES..............................................................................................10

PROJECT SCOPE..........................................................................................................12

PROJECT OUTCOME...................................................................................................13

PRELIMINARY INTERVIEWS............................................................................................14CHANGE PROCESS ANALYSIS.........................................................................................15

Classification of Changes..........................................................................................15Change Policy............................................................................................................16Change Data Repository............................................................................................16Change Notification...................................................................................................16Change Status Updates..............................................................................................17Change Feedback Mechanism...................................................................................17Integrating Current Change Processes.....................................................................17Approval Paths..........................................................................................................18Workflow....................................................................................................................18Change Teams...........................................................................................................18Change Coordinator..................................................................................................19Emergency Changes / Special Requests....................................................................19Prioritizing / Scheduling Changes.............................................................................19Change Fallback Plans..............................................................................................20Version Control / Release Levels...............................................................................20Change Data Requirements.......................................................................................20Change Descriptions.................................................................................................21Change Data Reporting Functions............................................................................21Testing of Changes....................................................................................................22Change Request Application......................................................................................22Production “Freeze Periods”....................................................................................23Synchronization of Changes Across Platforms..........................................................23Formal vs. Informal Change Processes.....................................................................23Resource Availability.................................................................................................24Web Application Turnover Process...........................................................................24Disaster Recovery and Change Management............................................................24Modernization: Infrastructure Management Tool Sets.............................................24Memos of Understanding (MOUs), Recovery Readiness Reviews (RRRs) and Service Level Agreements (SLAs)...........................................................................................25Help Desk Integration................................................................................................25Information Technology Infrastructure Library (ITIL).............................................25Planned Future Application of the ICMS (Cost and Trend Analysis).......................26

CONCLUSIONS..............................................................................................................27

5

RECOMMENDATION FOR AN IMPLEMENTATION STRATEGY....................29

APPENDIX A: TREND ANALYSIS FUNCTIONAL REQUIREMENTS...............33

APPENDIX B: COST ANALYSIS FUNCTIONAL REQUIREMENTS...................35

APPENDIX C: EXISTING BUSINESS RELATIONSHIPS.......................................36

APPENDIX D: INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY (ITIL).............................................................................................................37

APPENDIX E: REVIEW CURRENT CHANGE PROCESSES................................38

APPENDIX F: EXISTING CHANGE PROCESS CONDITIONS.............................39

Appendix G: Early Requirements Gathering.....................................................................40

6

Executive Summary

There are many reasons why we need to closely manage change in our fast-paced, volatile data processing environment. We need change controls in order to assure what state a production application will be in on a given day. We need to be able to control the many changes required to maintain consistent data processing/business relationships. Customers of our administrative information services may be reluctant to trust that their business is being conducted properly and their data is protected—such that their customers, in turn, can feel comfortable that they are receiving the best possible service for their money.

Another important benefit of managing change is the ability to relate changes to other IT management processes. For example, problem management, project management and asset and configuration management can all benefit from

7

having a direct data feed from a change management system. Moreover, we will have a much better opportunity to fulfill our auditing requirements.

All business thrives on competition. And in order to compete, we need to keep pace with our competitors. This inherent characteristic breeds data processing change with alarming rapidity! So it is no coincidence that change carries with it a great sense of responsibility. As our investigation continues we will learn more and more about how each change process is merely a part of a much bigger business data processing picture.

During the course of this project several areas of concern have been highlighted with respect to current practices for controlling changes within Administrative Information Services. A comparison to current adopted “industry standards” in the area of Change Management quickly reveals that we are (surprisingly) not very far behind the industry in these efforts. Nevertheless, based partly on this industry-wide comparison and partly on our own internal findings, there are some very compelling reasons to make every effort to enhance and evolve our current change processes into a more “formal” Integrated Change Management System (ICMS).

Our retrospective analysis indicates that the clear path to implementation is a “phased approach”. Phase 1 can be considered completed and is the culmination of the effort to create this document that summarizes the reasons for developing an integrated change management system. Herein we identify many of the specifications that will need to be considered. We recommend and lay the foundation for an implementation strategy, providing corroborating information for the completion of Phase 2 and a reflective strategy for future phases.

Phase 2 focuses on the completion of the groundwork provided in Phase 1 and tasks us with identifying Change Teams that will ultimately build the ICMS, defining and adopting an official “AIS Change Policy”, and developing a “Change Classification Matrix” among other things. A final review of existing change processes needs to be completed in order to ensure consistency in the new system. And finally, additional specifications must be generated to assist us in the software evaluation process. “Buy vs. Build” will need to be determined early on so that once a decision is made we can move forward, seamlessly.

Phase 3 follows the “buy” vs. “build” decision and begins a period where the estimated time line may blur a bit. There will be several unknowns to address during this time. Two separate implementation paths will need to be defined that identify tasks pertinent to each decision point. If a “Build” decision has been made, then the time line for the implementation process will be extended significantly. If a “Buy” decision has been made, then there will need to be an “evaluation period” added. In either case, Phase 3 will require some adept planning on our part in order to be successful.

8

Successful completion of Phases 2 and 3 constitutes the primary construction of the ICMS. Sometime during the implementation of Phases 2 and 3, a new project team should be formed to establish the criteria necessary for defining a project associated with Phases 4 through 6 that represent the ITIL model approach to put us on the path to true “Service Management” (of which Change Management is one of twelve “IT Service” components). These phases will focus on the areas of Disaster Recovery, Version Control/Release Levels and Problem and Asset and Configuration Management integration with the ICMS.

Change Management will have a significant impact on the development of a Disaster Recovery system. It is important to note that all change data collected for the change data repository during Phases 2 and 3 will be scrutinized as possible input to the Disaster Recovery “repository” (i.e. LDRPS). The ICMS should be able to provide information that can help determine the cause(s) of problems that may lead to a qualified disaster. At the same time, the ICMS should be able to help keep change data up-to-date in LDRPS.

Although the Enterprise Systems Development Modernization project was started near the end of the Change Management effort, it is important to note here that some of the Infrastructure Management Tool sets we are evaluating for the Modernization project overlap some of the Change Management tools that may eventually be recommended via the Change Management project. Hence, it is imperative that—where applicable—the two projects collaborate in this area.

The fundamental measure of success for this project is the realization—and acceptance—that the availability of a large number of existing AIS resources will be required to successfully complete Phases 2 and 3. Management’s full support and acceptance in this regard is essential to the success of the ICMS. We also need to recognize that the effects of doing Change Management are more far-reaching in scope than what may be developed within the confines of Administrative Information Services.

Project Background

There has been a growing uneasiness within Administrative Information Services that as we continue to expand outward—away from the traditional “enclosed” mainframe environment—toward a more flexible “open” distributed computing environment that the staid and true practices that were evolved and matured over a long history of (mainframe) application development are no longer being utilized in this new fast-changing environment. Borne by the frequency of demand for critical change requests, time-to-deployment has suddenly replaced quality control as the number one factor in moving applications and application changes into the production environment.

Even when the mainframe was the only viable business computing mechanism there was still a need to control change processes. Early on, it became evident

9

that changes to systems software/hardware, JCL, applications and/or production procedures required some level of control. At first, manual procedures for recording changes were prevalent. Later, as systems and applications matured, more formal processes were created out of the necessity to maintain a stable operating environment. Ensuring that a change worked as expected (i.e. testing), obtaining an appropriate “sign-off” that everything was in place and ready to move forward and documenting the details surrounding a change all became a standard set of requirements for change control. Procedures were developed and adopted as “required” processes in order to move a change into a production environment.

Over time, a variety of types of change processes evolved. However, they were each associated only with the area where they had relevance to a particular changed venue. There was very little “tie-back” to related processes—until the advent of IBM’s mainframe-based Information Management / Information Systems software suite. Included in this software were three components: (1) Problem Management, (2) Change Management and (3) Configuration Management. Unfortunately, only Problem Management was ever fully utilized. Consequently, there was still no way to relate information gathered in one of these components to any of the other components. Instead, we were only able to manage problems on a “search and comparison” basis—by searching the Problem Management database for symptoms of problems and comparing an existing problem’s symptoms with those kept in the database. Eventually, the AIS Support Center was established and a homegrown problem database replaced the IBM software. Meanwhile, change processes specific to individual areas within the organization continued to sprout, unchecked.

In the early 1990s, we entered the new world of “distributed computing”. The desire to get data out to the customer’s “desktop” became the driving force behind a radical paradigm shift in change processes. Many of these processes were never formalized and inevitably continued to grow out of control. Worse, there was no way to integrate these new fledgling change processes with the old “tried and true” (mainframe) processes. For a time, change control became rather chaotic. Somewhere along the way, there was a realization that the new distributed computing environment would also require stringent change control processes if we were ever going to keep ahead of the flood of change requests. But again, as past history would dictate, individual change processes continued to evolve. Very little could be tied together between application development environments or processes and existing change control mechanisms.

Eventually, the need for tighter controls for changes in the systems area became apparent. Production applications and/or servers were beginning to have a much higher “incident rate”. Coupled with the fact that the same number of systems personnel was still handling an ever-increasing number of changes, it made for a very stressful working environment. As a result, the systems area tried to initiate more stringent (manual) change control processes but was mostly unsuccessful

10

in stemming the tide of the onslaught of change requests. In parallel, some progress was being made in the area of managing projects (generally identified as large or significant change requests). A committee was formed and instantiated a formal “application turnover process”. Fully intended as a management tool for projects—from inception to implementation—the process drew both positive and negative feedback. On the plus side, more control could be exercised over major project implementations. On the minus side, the “perception” grew that this was merely another obstacle that slowed down the progress of an application’s development. Further fuelling the naysayer, management of changes (i.e. anything that might not be considered a major application implementation) was not included as part of the original design of the turnover process!

From a purely systems management point of view, the turnover process was a success in that it alleviated much of the pressure/burden being placed on the systems area to provide “immediate” response to each and every new set of project requirements. Over time, this evolved into the current “Web Application Turnover” process we utilize today. However, through a need to record and control all changes, the line began to blur between major application revisions and minor changes. Developers began to question why some of their (minor) changes were made to go through this (tedious) process. Today, there exists a lot of confusion with respect to exactly which changes/revisions need to go through this process. Consequently, the original intent of the turnover process has been lost!

This brings us to the present day. Though the aforementioned are but a few of the many issues raised throughout the life of this project, it is very clear that a new set of requirements needs to be developed to help us relieve the ever-widening separation of change processes that continues to occur over time. We truly need to create some new standards for integrating distributed systems and mainframe change management processes in our ever-changing environment.

Project Objectives

When we first started to outline the goals for this project, it became very clear that the scope of this effort could become unmanageable. Therefore, we immediately began to impose limiting parameters on the project goals. (This will be more clearly defined in the next section). Meanwhile, we still had to keep in mind our primary objectives.

First, it became quite clear that we do not currently have any mechanism in place to provide us with any type of change statistics. One of the primary goals must therefore be the establishment of a change metrics repository. But in order to do this, we will also need to develop a set of requirements for managing change in our environment. This in turn will require us to be able to differentiate between change control, change processes and change management. Our existing

11

change processes will need to be analyzed to find “best fit” practices that should be carried forward to the new system.

We will need to establish a policy for effective communication of changes across the organization. We will also need to recommend a methodology for prioritizing and scheduling changes. “Emergency changes” will require special attention in detailing how we will handle them. Standardization of existing change processes must be a minimum requirement.

All of the following functions and/or processes need to be addressed:

1) Classification of changes2) Change approval 3) Auditing 4) Change control 5) Communication of changes6) Formal testing of changes7) Fallback plans8) Formal business processes9) Procedural changes10) Change forms11) Change reviews12) Change Coordinator 13) Web Application Turnover 14) Project Management15) Firewall change requests16) Memos of Understanding17) Service Level Agreements18) Recovery Readiness Reviews

Disaster Recovery processes will need to be integrated with change management processes. Change data should be able to flow freely between these two sets of processes.

The new Workflow architecture must be fully understood in order to determine whether or not the new change management process can take advantage of its functionality.

Help Desk functions need to be investigated as potential integration candidates.

Existing change documentation repositories need to be able to be relocated to the new change data repository.

Cost analysis and trend analysis should be considered as a long-term change management measurement capability.

12

We must also ensure that there is some degree of project collaboration between this project and the Modernization Infrastructure Management Tools Selection process. There is obvious overlap to be considered.

Finally, the phased implementation plan needs to take into account the limiting of scope while at the same time being careful not to ignore any existing special business relationship requirements as we go forward.

All of the aforementioned objectives are covered in detail in the Project Outcome section and correspond to the goals set forth in the original Project Definition.

Project Scope

In order to maintain a reasonable pace and still be able to address all the issues at hand, it was determined early on that we would need to limit the scope of this project in some way. The primary limiting factor was staying within the confines of Administrative Information Services for all early phases of the project (except where it was deemed appropriate to explore outside conditions that may have a direct impact on any internal decision-making process).

Information flow will be restricted to existing internal AIS processes and any new internal AIS processes developed as a result of recommendations coming forth from this project. To the degree that it is feasible, we will explore data elements that may have direct—or indirect—ties to external AIS customers.

13

Software evaluation and implementation will be deemed “out of scope” for this phase of the project. However, follow-on exercises may be recommended as a result of research done during this project.

A “phased approach” is highly recommended as an implementation / planning vehicle for all subsequent project tasks. This will also serve as a scope-limiting mechanism.

Future consideration should be given to integrating the change management processes recommended in this project with existing ITS change management processes.

14

Project Outcome

After several iterations of different possible approaches to addressing goals and scope of the project, the following project tasks were completed:

a) Two AIS organizational groups were interviewed on an individual basis: (1) Management Team (2) Potential Project Team candidates

b) A project proposal and formal project definition were drafted(The project was officially entered into the AIS Project Status database)

c) The Project Team was selected—and approved

d) A preliminary review meeting was held

e) A communication listserv was established

f) The Information Technology Infrastructure Library (ITIL) was consulted(ITIL text/reference books were purchased as a project reference)

g) Monthly Project Team meetings were held

h) The Project Team analyzed the following Change Management areas (*):(1) Determine classification of changes (2) Recommend Change Management communications vehicle(3) Review and analyze Change Team concept(4) Review and analyze existing change processes(5) Review current Change Management industry standards(6) Review currently utilized AIS Change Process tools(7) Define “change” as it pertains to AIS (8) Define “Change Management” as it pertains to AIS(9) Determine change approval methodology

(10) Determine change metric repository specifications (11) Explore ways to integrate existing change doc repositories (12) Recommend methodology for prioritizing and scheduling changes (13) Define specifications for change control, testing, fallback and audit (14) How to integrate Change Management and Disaster Recovery (15) Outline roles and responsibilities for Change Management (16) Identify existing change policy definitions (17) Investigate Help Desk integration with Change Management

(*) Conclusive comments are included below.

i) This project report serves as a guide for mapping a strategy for implementing a formal Integrated Change Management System.

j) During the course of the project it was determined that there should be interim monthly meetings held in an effort to speed up the analysis effort.

k) Appendix A shows trend analysis functional requirements.

l) Appendix B shows cost analysis functional requirements.

m) Appendix C proffers some thoughts re measuring existing business relationships—in the context of Change Management.

n) Appendix D is a summary of the Information Technology Infrastructure Library (ITIL) and how the Change Management component is incorporated into this project.

o) Appendix E is a template from the Change Management process definition in the IT Services Information Plan/Project Plan found in the ITIL. It should be used to help us review current change processes.

p) Appendix F summarizes comments from the preliminary interviews re existing change process conditions.

q) Appendix G summarizes comments from the preliminary interviews re early requirements gathering.

Preliminary Interviews

To begin the project, individual interviews were conducted—first with the AIS management team, followed by all recommended candidates for the project team. Each interviewee was given the opportunity to voice opinions re the different aspects of Change Management. Comments on existing change processes as well as suggestions re how to create a more effective Change Management environment were discussed.

While the consensus among interviewees is that there are already change processes in effect for many areas within Administrative Information Services, it was unanimous that these processes are lacking in fundamental manageability structure. The conditions surrounding our existing change processes that contribute to the ineffectiveness of managing change in our current environment are highlighted in Appendix F.

One of the goals established for the project was to limit the scope, especially in the early stages, to managing only internal AIS change processes. The

16

preliminary interview process exposed a much wider breadth of scope than anticipated. A key challenge would be to get the project team to focus on only a core sampling of the issues. In this way, all of the primary issues could be addressed during the short life span of the project. Even with our efforts to narrow our focus it quickly became evident that there would be an enormous amount of work involved in identifying requirements and then bringing them together into a workable implementation plan.

Consequently, a series of questions was devised based on the interview results and adherence to the adopted project definition goals. These questions were used to stimulate discussion during the monthly meetings as well as to keep team members’ thought processes focused during the intervening periods of time. Appendix G highlights considerations raised during the interview process that ultimately led to the development of these questions. While this methodology paid off in terms of providing a rich set of discussion points, it was still difficult to bring some thought processes to a conclusive closure. As a result, the conclusions arrived at in this project are a somewhat complex mix of the Project Leader’s “interpretation” of the discussion results and the summary approval of the Project Team’s review of said “interpretations”.

Change Process Analysis

The following sections outline the results of the project team’s focused discussions on a wide variety of change process topics. In some cases, architectural design decisions still need to be made. One of the most difficult challenges early on was to conclude on a definition of change. As you will see throughout this report, a true definition of change—in our environment—must involve a correlation of all of the information included herein.

Classification of Changes

A multi-dimensional matrix will need to be employed in order to ensure that we develop a consistent classification schema that allows us to focus on the depth and breadth of any change. One of the primary elements of this matrix needs to be “risk”. We will need to develop a measurement model that can help us determine the level of risk involved in each change. In some cases we will be forced to rely solely on experience to make such judgments. Levels of complexity for a change do not necessarily map directly to risk but nonetheless will also need to be defined in the matrix. Estimated time-to-deployment should also be considered as a factor in determining the classification of a change. It will be very important that we are consistent across all levels. In all cases, there must be accountability for every change. Exceptions must be kept to a minimum and should always require upper management approval. Finally, however a change gets classified, we must be able to keep it moving through the process (i.e. we should build a proxy approval mechanism into our design).

17

Change Policy

We need to establish where the change management process will begin. While the ultimate change request may in fact originate at the end-user level, we should nonetheless become engaged in the process only after the change request has been entered into the ICMS. All changes that enter the system should be required to contain a brief description of the change. Also, a description of a back-out procedure must be included. All change requests will be filtered to determine a classification and priority. A centralized change data repository will be maintained and we will provide a change reporting mechanism to allow requesters to follow the status of their change request—from start to finish.

We must also be able to enforce accountability for each and every change. In this regard, we will need to be able to guarantee that change data entry is easy enough for anyone to initiate. We need to ensure that last-minute (e.g. emergency) changes are not able to bypass the system. In fact, all last-minute change requests should automatically void the original change request. Any reporting mechanism employed should be able to show historical data so that patterns of procedures not followed can be highlighted. Changes that work must also be recorded as a statistic.

Change Data Repository

The primary vehicle for capturing change information will be a Change Data Repository. (The type of database and/or file system used for the repository will not be decided until the implementation phase of this project). Data input to the repository must be consistent and concise. There must be a way to link all data areas that are (potentially) affected by any change. A search capability must be provided for impact analysis. The repository must be able to house the following types of data: common data elements (e.g. name, date, etc.), text, Word documents, Excel spread sheets and Adobe portable document format (pdf) files. A function-rich repository reporting mechanism must be provided. The change data repository and its reporting mechanism will be the key building block components developed and deployed in the early phases of the implementation of the ICMS. Minimally, this will provide us with an immediate change-tracking capability for audit purposes.

Change Notification

Communication of changes must occur very early in the process. The sooner change requests are initiated the more time there is to react to unexpected and/or unintended situations. We need to be more realistic in determining a time line for implementing a change and this can only happen when everyone is on board at the same time. Email seems to be the most often used form of notification today. This method can work—as long as everyone adheres to the same standard. It is important to provide a consistent means of communicating

18

changes. One recommendation in this regard is that we develop a change notification system that can utilize both email and the newly proposed Web Change Request application (see pp. 22-23 of this document), thus providing a more consistent, connected communication vehicle for all changes.

Change Status Updates

We need a way to provide a timely, consistent update of the status of any change. A single view Web page should provide the ability to check on the status of all recently applied changes. This functionality must be available to everyone—including management, developers, the Change Coordinator, the Change Team(s), and most importantly the Change Requestor. There should also be a capability to show all changes that are related in some way such that one may determine what might be holding up a change in progress.

Change Feedback Mechanism

Following in line behind a notification process and a change status update capability, there should also be a way to provide feedback at all levels of the change process. The Workflow process may be employed for this purpose. There should be a change record linking mechanism that provides information on all related changes. (This functionality could present security issues with respect to the viewing of sensitive information). Displaying/Presentation of pertinent information could also be a challenge.

Integrating Current Change Processes

Current change processes have been described as “consistently inconsistent”. Methods we utilize to record change information vary widely. Before we can integrate these processes we need to strive to be more consistent in the type of change data we collect. Most of our existing change processes are specific to different organizational areas. There is much duplication of effort. In order to design an effective ICMS, we need to establish a set of standards that every development area is required to follow. This must be mandated at a high level (of management). The implementation strategy recommendation for this project will include more specific detail re how we can integrate our current change processes into the new ICMS.

We will need to determine whether or not data captured in existing change processes can be used to populate primary and/or secondary change request form information. We should also look into whether we can somehow migrate existing change process data into the new system.

19

Approval Paths

The most effective way to ensure accountability for changes is to require each and every change to go through an approval process. Today, there are several instances where changes are implemented without any prior approval or acknowledgement of any kind! Some change processes are (unofficially) declared as “optional”. If we are to ever attain full accountability for changes, then we first need to establish approval paths. Concern has been expressed over the length of time that may be added to the completion of change requests. Therefore, we must develop a simple, well-designed approval process that provides for a “proxy approver” capability.

Workflow

The Workflow Project has been under way for several months. There are likely functions being developed for the workflow process that could be utilized by the new ICMS (e.g. approval paths). The Change Management Team should work with the Workflow Project Team to determine whether there is any overlap between the two projects. Since the implementation plan for the ICMS is still being developed, the Change Management Team will need to take the initiative to arrange meetings with the Workflow Project Team. This should be mapped out as an implementation task.

Outside of any existing workflow project overlap, approval path functionality should be considered as a critical feature requirement in any evaluation of Change Management software. Authentication via Kerberos and authorization via LDAP are also highly desirable features for controlling access to approval paths.

Change Teams

Industry-wide there are examples of IT teams established for the sole purpose of reviewing change requests. While these teams may vary in composition, they all have the same goal: to provide a swift-moving process that can analyze a change, evaluate the risk associated with a change, determine the classification of a change based on selected criteria, prioritize a change, ensure the appropriate resources are allocated to effect the change, ensure that the proper authoritative sign-offs have been obtained and review a regular status report for all changes in the change management system to ensure consistency. These teams can be formed within specific areas of the organization and should be comprised of both management and non-management personnel. Cross-training and/or mentoring will need to be provided to make these teams effective.

A simple network of approval paths will be required to make these teams effective. A proxy capability must also be provided to ensure that the change implementation “chain” is never broken. A voting/decision-making process should be devised for each Change Team. Change Teams need to be able to determine

20

who is ultimately responsible to make a decision re each change. An escalation process should also be developed. Risk levels should be used to determine whether a change request needs to go through a “Change Advisory Board” or can be approved by a single Change Team. The AIS Senior Management team should be engaged in the change management process only when the Change Advisory Board cannot come to a decisive conclusion during the process. Each Change Team should also (s)elect a Change Coordinator.

Change Coordinator

The Change Coordinator will lead a Change Team and coordinate all change requests that are funnelled through his/her Change Team. Each Change Coordinator appointed/selected should be at the organizational level of Manager or Supervisor. The Change Coordinator may also be asked to sit on a “Change Advisory Board” comprised of all of the Change Coordinators for all Change Teams within AIS. This review board could then be used as a final change request governing body that determines the outcome of undecided change requests before having to send them up to the Senior Management Team.

Emergency Changes / Special Requests

All emergency changes and “special” change requests will require high-level management approval. These types of changes must not be allowed to bypass any of the required change implementation procedures. Regardless of the emergency or “special case”, proper risk assessment and scope definition must be completed before implementing the change. A specified minimum amount of change information must be entered into the repository before the change will be scheduled.

Prioritizing / Scheduling Changes

There are differing views of priority levels within the AIS organization. There needs to be some form of “conflict resolution” incorporated into this process. Risk assessment (i.e. impact) and the scope of a change must be analyzed before assigning a priority. Priority assignment should occur when the change is scheduled (not as soon as it has been entered into the repository), taking into account changes already scheduled and the availability of resources required for implementing the change. Notification of priority assignments and/or changes should be made across all organizational boundaries.

Creating a consistent scheduling process for changes can be a daunting task. There is no set calendar for most existing change processes today. Therefore, we will need to establish some solid criteria for determining any type of regular schedule for implementing changes. Some possible scheduling factors include change category, platform, routine requests, change preparation time, change implementation time, automation capability, criteria specific to an area, test

21

period required, time required to back out change, related change effect, change frequency, change regularity, batched requests, change releases and versions.

Change Fallback Plans

All change requests should include a back-out plan. These plans should be tied to some specified time period after implementation occurs. There is also some sentiment that fallback plans should be tied to risk (e.g. limited risk changes would not require a fallback plan). This may require more work on the part of the Change Teams evaluating the level of risk deemed as “limited”. Regardless, all change requests should minimally provide documentation describing the change in detail so that the change(s) may be traced back.

Version Control / Release Levels

Current version control processes are complex. There are different processes being used across platforms that do not tie together very well. Before we can implement version control across the organization, we need to be able to identify common information such as a control record created for each version minimally containing date and a version number. There are also issues with maintaining vendor-supplied version numbers vs. internal version numbers. While there is some ongoing investigation into versioning software, it will be important to find something that can be integrated into the overall ICMS solution.

Providing release levels of application software changes would be a major step toward streamlining all of our change processes. Instead of doing changes as they are requested, change requests could be accumulated until there are enough to make a substantial release level change. The primary concern with this type of approach is that we would need to be sensitive to customer expectations. Time lines would become much more visible. Therefore, we will need to design something that can address this issue—and at the same time give us enough time to complete sets of change requests.

Change Data Requirements

The central change data repository concept is at the heart of the ICMS solution. At a very minimum, the repository will provide a history of all changes that are implemented. This information alone will be invaluable in helping us define trends, track problems and provide audit trails for changes. We will also be able to show actual change implementation time lines (on average over time), allowing us to give better estimates to our customers for when a particular type of change can be implemented. The big challenge in developing such an information repository will be in organizing all the disparate information. In addition, some change data may be considered sensitive for sharing among organizational units and as such we will need to develop some security access model for the repository. Common change data elements that have been

22

recommended to be included as part of a primary change request form are as follows:

Change Requestor NameChange Requestor Phone #Name of SupervisorData Steward IndicatorDate Change Request SubmittedRequested Change Implementation DateAlternate Contact Change DescriptionAssociated Documentation

The Change Request form associated with the ICMS must contain a minimum of all of the above pieces of information. Information specific to the change request being made and/or change data related to the specific area making the request should also be captured. However, this “secondary data” should be easily obtained (i.e. preferably via an automated capture mechanism) and should also be entered via a secondary change request form that is somehow attached to the primary form. These secondary forms could also be used to link together change requests that are related—by application(s) impacted, by system(s) requested, by requestor, by date, etc.

One particular area of concern here is how we can capture the many different documentation types folks use to document their work. We could standardize on one data type (e.g. MS Word). However, due to the disparity between the many data types that are already in use, we may be better served by “standardizing” across several well-known data types (e.g. Excel, .pdf, .txt, Word). We can provide a supported list of these once we can agree on the list.

Change Descriptions

For simplicity in the early stages of the ICMS development, change descriptions will be accepted as simple free-form text. However, there should be sufficient information included such that the associated Change Team(s) can conduct an early risk assessment for the purpose of setting priorities. During the implementation phase(s) of the ICMS, there will be a review conducted to determine whether there should be additional metadata tied to each change description to be used as future search criteria.

Change Data Reporting Functions

Regardless of the final form of the change data repository, there will be a need to provide some type of reporting capability for the data housed there. Some of the more standard features that should be required include a data element cross-reference, related changes cross-reference, access to architectural diagrams

23

showing the overall effect of a change, automated information capture for a change notification process, change request lists sorted by various data elements, searching capability, access to documentation pertinent to any change and status of a change—or a set of related changes.

Testing of Changes

Testing procedures vary greatly from one functional area to another. Test periods can vary by application. Some areas require “acceptance testing” while some areas do not. There needs to be more integration of changes between organizational units—especially where there are interactions between applications and/or systems. There is incentive to move to a “release level” change environment. (Projects would represent “version level” changes). Changes would be better managed if we could institute monthly cycles. Changes can be “batched together” into a new “release level” of the application and/or software involved. We should also make it mandatory that a Manager signs off on the testing of all changes before moving forward. Developers should be responsible for making requests to move from the test environment to the acceptance environment. Managers should be responsible for making requests to move from acceptance to production. The original customer should be included in the final approval. Enforcement—or non-enforcement—of these adopted standards will be key to the success—or failure—of the ICMS.

Change Request Application

There is an urgent need to clearly distinguish a change request from a project request. The current Web Application Turnover process was originally designed to manage major enhancements to existing applications/systems or additions of new application/system functionality. The process was not designed to handle smaller changes to the existing application—or system—environments. However, over time we have forced many such changes through this cumbersome process. We need to develop and build a new process to deal with simple change requests. This new process then needs to be incorporated into the new ICMS. The ultimate decision as to whether a particular “change request” is significant enough to warrant a major enhancement or new addition should rest with the Change Teams, the Change Advisory Board and/or the Senior Management Team. In any case, there should be two separate and distinct processes—one for change requests and one for requests for application enhancements or new additions—built into the new ICMS.

The new processes must be simple and easy for people to use. Anyone within the university community (with a valid access account) should be able to make a change request. However, in order to ensure that change requests are funnelled through proper channels, we should limit who has access to the change request application and then establish a policy based on the prescribed access limitation(s). We also need to develop/provide multiple change request forms that

24

can be accessed from the same (Web) application. Several “request for service” forms exist in our organization today. These should be reviewed as a possible blueprint for the ICMS. Regardless of method or location, there should be only one place to go to manage changes.

There needs to be a way to automate the capture of information from the change request form(s). The workflow process should be investigated to determine how it might be used to help us automate some (or all) of the change management processes. A change request filtering capability should be provided as well. AIS Consultants can assist with getting changes into production. And for the purposes of this project, change initiation beyond AIS should be considered outside the scope.

Production “Freeze Periods”

The Change Team(s) will determine the validity of any change request made during a “freeze period”. These change requests must still go through the new ICMS change process, obtaining upper management approval before proceeding. In addition, there should be a field in the change data repository to denote if/when a change request is passed through during a freeze period. This will be used to gather statistics about the success/failure of such changes—and their frequency.

Synchronization of Changes Across Platforms

Today, we have several methods in play to help us determine when it is OK for a change to be moved into production. For example, the Mid-Tier Infrastructure group awaits notification from the developer before moving forward; eLion employs the use of a Change Form; CA-7 synchronizes change procedures on the mainframe. Back-outs of ill-begotten changes must also be synchronized—although these are still manual processes. Any new Change Management tool should strike a balance between disparate platforms (e.g. cross-platform scheduling that triggers jobs/processes to run on other systems would be a plus).

Reporting on the status of a change is deemed more critical than the actual back-out process (base awareness is critical). Notification of a problem/issue is required at all levels. Frequency of application execution should be recorded as a data element. Related change information needs to be collected and reported. An audit trail of change processes is needed and all inter-dependencies should be mapped.

Formal vs. Informal Change Processes

While all changes should be considered “formal”, priority should be assigned based on associated risk level. The impact of a change could be dependent on the time of year. In order to measure the cost of “not doing a change” we need to

25

classify risk assessment. This may be accomplished by relying on experience (known impact of past changes in a particular area). Planned vs. unplanned changes also need to be taken into account.

Resource Availability

Over time, as we develop the new ICMS, advanced notice for change implementation should be a standard policy requirement. This may simply become a reporting issue—we will want to notify affected parties immediately when resources may not be available. This will require us to manage all change requests. Routine changes should be handled via specific groups but expectations still need to be managed.

Web Application Turnover Process

The consensus is that the existing process is outdated and too cumbersome to be used as a change management vehicle. This process should be re-designed and built into the new ICMS. Ideally, it should be made available as one of the “services” provided by the ICMS.

Disaster Recovery and Change Management

However we design the ICMS, we need to find a way to integrate the Change Management process with the Disaster Recovery process. This will entail a detailed analysis of the LDRPS software, the Change Data Repository, reporting functionality of both and the design of the Change Request form. In some way we must ensure that an appropriate subset of change data is also captured in the Disaster Recovery data repository. Processes on both sides need to be evaluated to determine whether there is overlap. Some processes from one may need to be infused into the other. This is the only way that we can ensure that changed environments are documented consistently for Disaster Recovery purposes.

Modernization: Infrastructure Management Tool Sets

If we decide to “buy” (vs. “build”) software re the ICMS, then we will need to pay very close attention to the Infrastructure Management Tool Selection process of the Enterprise Systems Development Modernization project. There will certainly be overlap between these two efforts. In particular, where there are requirements to manage change in our new application development area, anything in the area of WebSphere Java development change management can be construed as being part of the Modernization project—especially with respect to a funding model.

26

Memos of Understanding (MOUs), Recovery Readiness Reviews (RRRs) and Service Level Agreements (SLAs)

Change Management will have a significant impact on measuring the success/failure of MOUs and SLAs. Outages that can be directly associated with change(s) will be able to be measured via ICMS reporting mechanisms. Differentiation between “normal vs. abnormal” and “scheduled vs. unscheduled” outages can be provided. Statistical data can also reveal pure numbers such as how many times a certain situation occurred.

Change Management can also have a significant impact on feeding change information to the RRR process. Recoverability may be jeopardized by changes that have been made—especially if they have not been documented.

There needs to be a way to measure accountability between departments and the service organization. For starters, copies of MOUs, SLAs and RRR documentation should be kept in the Change Data Repository. This is obviously an area where we must cross over and engage our user community in order to make the ICMS a success.

Help Desk Integration

The current ITS/AIS Help Desk utilizes a Problem Management database to record and register incoming service calls. Calls may be handled directly or directed into a primary- or secondary-level support structure. Our investigations led us to the unfortunate discovery that not all problem resolutions are captured (i.e. documented). We need to do a better job of categorizing types of problems and/or changes in order to provide a usable cross-reference of information that relates to both problems and changes. Essentially, data must be captured in a way that is more readily reportable. This will in turn allow the Support Center to be more proactively responsive to problem situations as they are reported. This pertains primarily to online services.

Information Technology Infrastructure Library (ITIL)

While not heavily practiced in the United States to date, the ITIL set of standards has been around in Europe for quite some time. There seems to be a lot of interest in the ITIL being generated recently in the U.S. For the purposes of this project, we did employ some of the various ITIL component templates in creating some of this report. Also, we spent some time reading and reviewing ITIL components related to Change Management. It is evident from this effort that a robust “Service Support” structure can be modelled after the ITIL set of standards. Reference Appendix D for additional information re the ITIL.

27

Planned Future Application of the ICMS (Cost and Trend Analysis)

Once we have a change data repository in place and we have been collecting change data for some period of time (minimally a 6-month period), we should then be able to begin to fully utilize the data collected. Statistical data collected can be used to identify trends. For example, we might like to know how many changes occurred during a given time period. Associatively, assuming we also have some statistical data re problems, we should also be able to correlate any changes that may be a direct root cause of a particular problem. This is just one area where the new ICMS will begin to pay dividends! By classification, we should also be able to see any trends that indicate that certain types of changes require more attention to detail. Hence, we will be better able to plan and schedule such changes. Resource allocation can also be derived from this kind of analysis data. By utilizing trend analysis to its fullest, over time we should become much more efficient at implementing changes.

Measuring cost may be a little more difficult. For this we will need some financial guidance. For instance, how should we “charge” for a resource involved in the change process? Given a base estimate per hour charge for a particular resource, initially we should be able to correlate the number of person hours required to implement a change with a cost per change value. The difficulty with this type of analysis comes with disparities in salaries associated with individual resources. However, if we simply assign some arbitrary per hour charge for “change services”, we could still derive a very useful cost trend analysis over time. Most of the details in this area will need to be flushed out during the implementation phases of the project.

28

Conclusions

Clearly, the prescription for an Integrated Change Management System set forth in this document poses a formidable challenge. There are many variables involved and some imposing obstacles to overcome. Based on these premises alone, we can conclude that the only way to successfully implement such a system is to utilize a phased approach. Hence, the “Recommendation for an Implementation Strategy” proffered below outlines such a strategy.

First, an Implementation Team needs to be assembled. The membership of this team should be comprised of a small number of “implementation assistants” who act as project implementation advisors to the Change Teams. Change Management Project Team members may—or may not—be selected as part of this new team. Those team members who are not selected to participate in the implementation process can be called upon as consultants.

The first task of the Implementation Team will be to help to establish official “Change Teams” for AIS and then assist them in defining their (individual) charters. Minimally, a “Change Team” must be comprised of at least two individuals. (Each Change Team would in turn be responsible for (s)electing its own “Change Coordinator”). Once the Change Teams have been created and all Change Coordinators have been (s)elected, the new “Change Advisory Board” will—by definition—be established (i.e. comprised of the Change Coordinators). The first task of the new Change Advisory Board will be to adopt an official “Change Policy” for AIS. Next, the Change Teams will be tasked with developing a “Change Classification Matrix”. (As we move forward, there are several areas where additional investigative effort will be required and some design work still needs to be completed. The original Change Management Project Team may be instructed to assist in completing these efforts, along with the Implementation Team).

Meanwhile, the Implementation Team and Change Teams can continue to work on subsequent steps outlined in the Implementation Plan. The Change Teams should conduct a final review of the existing AIS change processes in order to finalize the requirements to be used during the evaluation of ICMS software and/or solutions. It is important to fully understand how our current change process environment is documented—before moving forward. A clear transition plan must be developed for migrating from each existing AIS change process to the new structure.

Once the aforementioned steps have been completed, it is time to develop and publish the specifications for both the “Change Data Request Form” and the “Change Data Repository”. These two change-tracking mechanisms must be designed to complement each other and should follow suggestions outlined in the Project Outcome section of this document.

29

Next, change request approval paths need to be established for each “Change Type” identified by the “Change Classification Matrix”. At this point, the current “Workflow Project Team” should be consulted to determine whether methodologies devised for Workflow and/or the software itself could also be utilized here.

Once the specifications for a “Change Data Request Form” and a “Change Data Repository” have been developed, it is time to outline the specifications for a new Web-based “Change Request Application”. This new application must be able to integrate these two newly developed change-tracking mechanisms. In addition, specifications for a “Change Notification Process”, a “Conflict Resolution Process” (for prioritizing and scheduling changes), “Change Management Reporting and Monitoring Functions”, and a “Change Testing Process” must also be developed.

Based on the previously outlined specifications, a selection guideline for the evaluation of tools can be produced. This guideline should be used to evaluate potential ICMS software solutions. Where necessary, vendors may be called upon to assist in the evaluation process. An estimated cost for current change processes should be provided as a base comparison.

The evaluation process could take longer than anticipated, as there are variables outside the control of the Implementation Team. Once a tool set has been selected, adequate skills transfer and training needs to be provided. Ongoing support also needs to be established.

At this point, it is time to engage AIS Senior Management in establishing a set of roles, responsibilities and training requirements emphasizing the philosophy of Change Management for the AIS organization. These should be incorporated into change processes documented by the Change Teams. AIS Senior Management should also be consulted to identify any required business process interfaces that might be provided via the selected tools.

At the completion of this effort, the AIS Senior Management Team should be asked to sign off on the new ICMS. Once this has been done, an official announcement can be made re the availability of the new Integrated Change Management System.

Although the topics of Disaster Recovery, Help Desk, Version/Release Control, Problem and Asset and Configuration Management were discussed as part of the analysis efforts for this project, it is the recommendation of the Project Team, that further investigation beyond the scope of this project is required in order to effectively integrate these disparate areas into the new ICMS. It is therefore left as a future exercise to determine how to incorporate these.

30

Recommendation for an Implementation Strategy

As the project report indicates, a phased approach has been recommended for implementing the Integrated Change Management System in AIS. Ultimately, this will involve several phases, carried out over an estimated multi-year period.

Many of the requirements have now been documented. While some of the recommendations have clearly defined implementation boundaries, there are still a few that will require further research during the implementation process. The implementation tasks listed here are derived from the requirements analysis done to this point. Those tasks requiring additional investigative research will be so noted herein.

STEPS (Phase I) NOTES/ /RELEVANCE/DATES/W

HO

Define the Objective and Scope for Change Management in AIS.

(Create Project Definition).

Completed.

CM Project Team

Establish and agree on a clear definition for the word “Change” within the context of the AIS IT Infrastructure.

Completed.

CM Project Team

Seek initial approval.

(Project Definition accepted).

Completed.

Sr. Management Team

Preliminary Requirements AnalysisCompleted.

CM Project Team

STEPS (Phase 2) NOTES/ /RELEVANCE/DATES/W

31

HO

Establish Implementation Team1/31/2006

CM Project Team

Establish Change Team(s) and Define Charter(s). Minimize training, education and implementation time lines by reusing some of the existing skills base.

(S)Elect Change Coordinator for each Change Team.

(By default, the Change Advisory Board will be comprised of a Change Coordinator from each Change Team).

1/31/2006

1/31/2006

Implementation Team (With recommendations from CM Project Team)

Change Teams

Adopt an official Change Policy.

(Complete work started by CM Project Team).

2/28/2006

Change Advisory Board

Develop a Change Classification Matrix.

(Complete work started by CM Project Team; the matrix will be multi-dimensional).

3/31/2006

Change Teams + Implementation Team

Review existing CM practices in greater detail. Review current process connections from these practices to other areas of IT Service Delivery and Support. Incorporate “best practice” standards of existing change processes as specific requirements criteria for software evaluation.

(See Appendix E for suggested review areas).

3/31/2006

Change Teams + Implementation Team

Document the transition from current change process format to any new format that is selected.

4/15/2006

Change Teams + Implementation Team

Develop specifications for a Change Data Request form and a Change Data Repository.

(Ensure request form and repository are in synch).

4/30/2006

Change Teams + Implementation Team

STEPS (Phase 2—continued) NOTES/ /RELEVANCE/DATES/W

32

HO

Determine appropriate change approval path(s) for each change type.

(Explore Workflow approval path methodology; ensure proxy approver capability).

4/30/2006

Change Teams + Implementation Team

Develop specifications for a new (Web-based) Change Request Application.

4/30/2006

Change Teams + Implementation Team

Develop specifications for a change notification process.4/30/2006

Change Teams + Implementation Team

Develop specifications for a “conflict resolution process” for prioritizing and scheduling changes.

4/30/2006

Change Teams + Implementation Team

Develop specifications for change management reporting and monitoring functions.

4/30/2006

Change Teams + Implementation Team

Define a change testing process (specification).5/31/2006

Change Teams + Implementation Team

Establish a selection guideline for the evaluation and selection of tools based on the specifications developed.

6/30/2006

Change Teams + Implementation Team

Evaluate potential ICMS software solutions. Decide how best to select any vendor that will provide assistance in the evaluation process.

7/31/2006

Change Teams + Implementation Team + Infrastructure

Select ICMS software solutions. As cost will be a major factor in the decision, an estimated cost for current change processes should be provided for comparison.

(Make recommendation for build vs. purchase).

8/31/2006

Change Teams + Implementation Team + Infrastructure

STEPS (Phase 3) NOTES/

33

FUTURE TASKS (Phases 4 - 6) /RELEVANCE/DATES/WHO

Purchase/Build and install ICMS software solutions. If purchased, ensure adequate skills transfer (education and training) and on-going support is provided.

TBD

Infrastructure and AIS Senior Management

Document and get agreement on roles, responsibilities and training plans.

TBD

Change Teams and AIS Senior Management

Create any required business process interfaces that can be provided via the selected (automated) tools.

(Reporting: frequency + content).

TBD

AIS Senior Management

Announce availability of the new ICMS.TBD (estimate: 2Q07)

AIS Senior Management

Integrate ICMS solutions with Disaster Recovery Process

(Phase 4: ICMS integration with LDRPS software—should be a separate project).

TBD

Change Teams + Implementation Team + Infrastructure + DR Team

Implement Version Control / Release Level Process

(Phase 5: Should be a separate project).

TBD

Change Teams + Implementation Team + Infrastructure + Application Developers

Integrate Problem and Asset/Configuration Management into the ICMS.

(Phase 6: Should be a separate project).

TBD

Change Teams + Implementation Team + Others (TBD)

It is important to re-emphasize that the above implementation strategy can only succeed if appropriate resources are allocated.

34

Appendix A: Trend Analysis Functional Requirements

The change data repository will afford us the opportunity to generate statistics that can help us measure how well we are managing changes. General statistics will initially give us an inside look at raw numbers. Trends can be revealed over time. The following list shows some of the functional trends that we can show assuming we can capture all the appropriate change data:

Number of changes in a given period…Daily …3 8-hour periods…Weekly…Monthly…Yearly…During a freeze period…Per semester (where this might make sense)

Number of changes by classification (i.e. type of change)…“High risk” changes…“Medium risk” changes…“Low risk” changes…“High complexity” changes…“Medium complexity” changes…“Low complexity” changes…”Short-term implementation” changes…”Long-term implementation” changes…”Exceptions”

Number of changes by group (i.e. area within AIS)…Enterprise Infrastructure…Network Infrastructure & Data Security…Mid-Tier Infrastructure…Computer Operations and Facilities…Solutions and Service

Amount of time required for completion of a change (from start to finish)

Success/Failure of a change

Change notification sent

Number of priority requests…High…Medium…Low

35

Change data requirements checklist…All sign-offs obtained…Description of change entered…Back-out procedure included…Change tested (indicator)

Change synchronization (indicator) across platforms

Change delay/status information…Resource availability…Risk involved…Complexity…Time of year conflict (e.g. freeze period)…Requirement(s) not fulfilled

Number of change requests passed on to the Change Advisory Board as a percentage of the overall number of change requests

Number of change requests passed on to Senior Management as a percentage of the overall number of change requests

In addition to reporting the above functional change data statistics, once we can also integrate the ICMS with problem management, we should be able to provide statistics that directly relate changes to problems (or vice versa). Configuration management is another area where we can benefit by integrating with change management. Both of these additional management components are also included as part of the Information Technology Infrastructure Library (ITIL) that we have explored as part of this project (reference Appendix D).

As Disaster Recovery and Version Control integration with Change Management will not be implemented until after the ICMS has been “activated”, the details of functional data requirements for these areas that will be incorporated with the trend analysis for change management will be left as an exercise for a future (implementation) phase of the project.

36

Appendix B: Cost Analysis Functional Requirements

The cost of process implementation is something that must be considered before, during and after the implementation initiative. If we follow the ITIL IT Services Implementation Plan/Project Plan for Change Management, there are several areas where we will need to focus our attention with respect to determining the true cost of the ICMS. Most of these costs should be budgeted for (or allocated) well in advance of expenditure. Therefore, part of the cost analysis will be to decide on whether to develop a charging mechanism (and if so, what type) for the new services to be offered.

Note: this may not apply during the early stages of this project since we are not engaging external customers at this time.

The Financial Management component of the ITIL describes cost analysis. Refer to Appendix D.

Some of the considerations for cost analysis are listed below as functional requirements. (Extracted from the ITIL Change Management Process outline).

Personnel – Costs of people for initial design of process, implementation and ongoing support.

Accommodation – Costs of housing new staff and any associated new equipment and space for documents or process related concepts.

Software – New tools required for support of the process and/or the costs of mitigation from an existing tool or system to the new one; maintenance costs.

Hardware – New hardware required for support of process activities. (Includes IT hardware and even new desks for staff).

Education – Re-education of existing staff to learn new techniques and/or learn to operate new systems.

Procedures – Development costs associated with filling in the detail of a process activity. The step-by-step recipe guides for all involved and even indirectly involved personnel.

37

Appendix C: Existing Business Relationships

While the initial stages of this project will focus on internal AIS Change Management, at some point it will be necessary to activate the new ICMS externally. Before we can do this effectively we will need to have a dialog with each and every external entity we hope to engage in this effort. First, we will need to inspect our current business relationships to determine the viability of using the ICMS to manage external changes. Hopefully, during the internal AIS deployment of the ICMS, we will have taken into consideration how what we have built might work in an external development environment. This is the only way to ensure some level of consistency as we try to adopt new change policies for all developers across the University.

Our recommendation in this regard is to begin to engage external developers at an early stage of the implementation process. Initially, this should be limited to a simple interview process—much like the early interview processes conducted for this project. Information gathered would be used as a guideline for implementation (i.e. if there is some question raised re an implementation task that perhaps does not fulfil an external developer requirement then we would have time to react to try to incorporate their needs). Toward the end of the implementation phase, we should then (re)-engage external developers in helping us test. We may even choose to include some subset of them to participate in a pilot of some phase(s) of the ICMS production implementation. Of course, this would require an agreement between AIS and the external developers that they would not be included in the early (internal AIS) production rollout. (Instead, those involved in the pilot could be promised to be included in the early stages of an external production rollout—in a later implementation phase). This is all subject to change depending on how the implementation process proceeds.

The bottom line is that at some point in the future we will need to require that all external developers use the ICMS. Again, this is the only way to guarantee consistency in the management of changes that affect AIS.

38

Appendix D: Information Technology Infrastructure Library (ITIL)

We became aware of the ITIL very early in the project. Perhaps the most interesting aspect of this set of international standards was our discovery that we are already on a path to exploiting several ITIL component strategies. In addition, we learned that several of our peer institutions (particularly those with some CIC relationship background) are also engaged in investigating the ITIL. While no one seems to have a clear “vision” re where this might lead, there is at least a consensus that this is something worth exploring. SUNY Buffalo appears to have taken the early lead in getting their upper management to support a full investigative effort in this regard. However, after an initial flurry of activity, there has been no recent communication.

So what is the ITIL? Rather than reprint all of the related documentation we have found here, we will simply provide a link to a Web site that does a very nice job summarizing the ITIL—and more importantly—from the perspective of Change Management (which happens to be just one of many ITIL components). The Web site is:

http://www.itilpeople.com/What%20is%20ITIL.htm

From the perspective of what we are currently attempting to accomplish Change Management is one of eleven different disciplines located within the “Service Management” section of the ITIL. Specifically, Change Management is located in the “Service Support” section of “Service Management”. One very important thing to understand re the ITIL is that it is a set of best practices standards for Information Technology service management. As such, ITIL is customizable and scaleable. It can be utilized by an organization to achieve quality of service.

For more detailed information re the ITIL, reference the aforementioned Web site. While this site shows the overall make-up of a large set of services, we primarily focused on the Change Management component for purposes of this project.

Some of the ITIL texts that we purchased and reviewed are also listed here for reference (see either Mike Belinc or Char Wilusz to check these out).

ITIL ToolkitThe Visible Ops Handbook: Starting ITIL in 4 Practical StepsLeading Change Strategies for Implementing Change Planning to Implement Service Management (ordered/not received)

39

Appendix E: Review Current Change Processes

It is critical to identify existing procedures/processes and people in place that feel that the activities of Change Management are already being done. These should be analyzed to determine their future role as part of the new process definition.

Areas to review are noted as follows:

Area Notes

Power teams (i.e. Change Approvers)

Current formal procedures

Current informal procedures

Current role descriptions

Existing organizational structure

Spreadsheets, databases and other repositories

Other…

40

Appendix F: Existing Change Process Conditions

Summary of Preliminary Interview Comments

Most change processes are home grown. Existing change processes are “individualized” to specific areas. Many changes are implemented without adequate documentation. Change policies are not always enforced. There are no tools available to effectively monitor and track changes. Change processes are inconsistent across the organization. Many changes are not adequately tested before implementing. Existing change processes are often confusing. Change processes are not well advertised across the organization. Change processes are non-existent for some applications. Some change processes are misconstrued as to their purpose. Change processes are sometimes indistinguishable from managed projects. Change processes are not enjoined with Disaster Recovery plans. We do not do a thorough job of risk assessment. Processes are sometimes duplicated. Changes are not prioritized consistently. Most change processes are manual (with some noted exceptions).

41

Appendix G: Early Requirements Gathering

Summary of Preliminary Interview Comments

It is strongly recommended that we provide a way to classify all changes. We need to provide a robust communications vehicle for change notification. We need to develop change approval path functionality. We must provide an audit trail for all changes. We must be able to enforce any formal Change Management process. We should have a central focal point for all changes in a given area. We need to develop a formal change testing process and incorporate it as

part of the Change Management process. Workflow should provide tie-in to external Change Management processes. We need to automate the Change Management processes wherever

possible. A formal policy needs to be developed for emergency changes; and it must

be enforceable. Risk assessment should be a high priority issue when defining levels of

change. All changes must be documented. Existing change processes and change forms should be integrated into the

new ICMS. We need to provide a link from the ICMS to Help Desk operations. Project Management should be integrated with Change Management. A central repository of change information should also include Problem

Management, Project Management, Asset and Configuration Management data.

The new ICMS should be able to interface with the Disaster Recovery process.

The Web Application Turnover process is too cumbersome, confusing, outdated and does not currently handle small changes very well—it needs to be completely redesigned; it should also incorporate software/system changes.

The change request process must be simplified. Recovery Readiness Reviews should be incorporated into the new ICMS. We must provide change metrics by which we can measure the

success/failure of our change processes. Some partner offices currently initiate changes outside the control of AIS; at

some point this will need to be addressed in the context of the new ICMS. Some functional areas of administrative computing have adopted change

process policies; whether or not these are managed by specific system functions or are manually managed, they all need to be integrated into the new system.

We must be able to exercise some control over who can initiate a change. The number of people who can submit change requests should be limited,

thus creating a funnelling effect for all changes.

42

We must be able to exercise some control over how many changes can occur in a given period of time.

Specific qualifications should be defined for resources allocated as “change agents”; Change Agents must have the authority to deny and/or delay change requests—based on some form of business impact analysis.

Once we have identified a more formal Change Management process, we will need to define clear, enforceable change policies.

Minimally, we need to provide guidelines for changes initiated external to AIS. We should require a clear definition of the purpose of any change. Support for 24x7 availability should be incorporated as criteria for change

approval. Projected change implementation time tables/schedules should be required. It should be a Manager who ensures that change processes are followed. Design and functional specification documentation should be required for all

changes. We must determine what/how much information needs to be collected to

ensure that a change is properly managed. Some of the onus for prioritization of changes must be placed at the Director

level of the organization (portfolio management vs. project management). Some type of “voting” methodology should be incorporated into the change

prioritization schema. A new change request form needs to be designed and developed (today we

can have upwards to 9 different change request forms active at any time!). Resource availability plays an integral part in what we will be able to

implement. We need to be able to clearly distinguish between a “User” and a “Customer”. How can we measure the success/failure of a change? …Via cost analysis, trend analysis and the ability to associate changes

directly with problems. How do we make people use Change Management? …Suggestion: unless change goes through the process, it does not happen! Should we require a walk-through for changes? To what level of change? …We need to be wary of time lines and resource constraints. Back-out processes should be required as part of a change request. What are the data feeds to a central change data repository? …How can we automate this part of the process? Versioning should be considered as an integral part of the ICMS. We should have a periodic review of changes by Senior Management. We need Management support for Change Management as a priority project

—we will likely need to give something up in order to implement an ICMS. We need to define—and be able to readily recognize—impact areas. Interdependencies among application development areas must be identified. In order to facilitate simplicity, we may need to provide authenticated viewing

capability for certain areas of the central change data repository. How will we manage the myriad of “system tweaks” that occur on a regular

basis?

43

Can we provide a capability to measure the unintended effects of a change? We need a robust reporting capability for the change data repository. We need to pay more attention to customer requirements. We need to be able to begin capturing data at the pre-design phase—and

then continue to collect information throughout the life of a change. Change processes need to be streamlined across all platforms. We should always come to a mutual agreement with the customer before

implementing changes. The current “Change Committee” function should also be incorporated into

the new system. We need to do a better job of advertising exactly what services we provide. We need to do a better job of enforcing “freeze periods”. We need to provide a more immediate feedback mechanism for changes. There needs to be more emphasis placed on change process accountability. Can we design a Web site that provides instant access to all change

procedures? (Suggestion: AIS Portal). Much of the information re changes is currently captured only within private

files and/or email folders of individual change agents. Some areas generate change “wish lists” with users. LDRPS provides the capability to download documents into Disaster

Recovery plans. We need a Web-accessible central repository for all product installation

software. Existing “Request for Services” and “File Control System” change processes

should be thoroughly reviewed as potential models for the new ICMS. In its entirety, Workflow is a complex set of processes. Required paper work (i.e. “Red Tape”) must be kept to an absolute minimum. Program source code is currently stored in several different places.

44