Administrative Information Services
Change Management Project
Phase 1: Requirements Analysis
Authored By: Mike Belinc, Enterprise Systems Architect
Date: December 20, 2005
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 Interviewees (AIS Management Team—Not on Project Team)
Project Interviewees (Project Team Candidates—Not on Project Team)
Dave Hoover (1)
Greg Von Kuster
(1) Dave was selected but later replaced due to change in jobs.
Table of Contents
PROJECT ACKNOWLEDGEMENTS .........................................................................2
PROJECT OBJECTIVES .............................................................................................10
PROJECT SCOPE .........................................................................................................12
CHANGE PROCESS ANALYSIS...............................................................................................15
Classification of Changes..........................................................................................15
Change Data Repository...........................................................................................16
Change Status Updates..............................................................................................17
Change Feedback Mechanism...................................................................................17
Integrating Current Change Processes.....................................................................17
Emergency Changes / Special Requests....................................................................19
Prioritizing / Scheduling Changes.............................................................................19
Change Fallback Plans.............................................................................................20
Version Control / Release Levels..............................................................................20
Change Data Requirements.......................................................................................20
Change Data Reporting Functions............................................................................21
Testing of Changes....................................................................................................22
Change Request Application.....................................................................................22
Production “Freeze Periods”...................................................................................23
Synchronization of Changes Across Platforms ........................................................23
Formal vs. Informal Change Processes....................................................................23
Web Application Turnover Process...........................................................................24
Disaster Recovery and Change Management...........................................................24
Modernization: Infrastructure Management Tool Sets.............................................24
Memos of Understanding (MOUs), Recovery Readiness Reviews (RRRs) and Service
Level Agreements (SLAs)...........................................................................................25
Help Desk Integration...............................................................................................25
Information Technology Infrastructure Library (ITIL).............................................25
Planned Future Application of the ICMS (Cost and Trend Analysis).......................26
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
APPENDIX E: REVIEW CURRENT CHANGE PROCESSES ..............................38
APPENDIX F: EXISTING CHANGE PROCESS CONDITIONS............................39
APPENDIX G: EARLY REQUIREMENTS GATHERING......................................40
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
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
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.
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.
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
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
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
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
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.
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
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 changes
2) Change approval
4) Change control
5) Communication of changes
6) Formal testing of changes
7) Fallback plans
8) Formal business processes
9) Procedural changes
10) Change forms
11) Change reviews
12) Change Coordinator
13) Web Application Turnover
14) Project Management
15) Firewall change requests
16) Memos of Understanding
17) Service Level Agreements
18) 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
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.
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.
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.
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
Future consideration should be given to integrating the change management
processes recommended in this project with existing ITS change management
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.
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
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).
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.
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
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.
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.
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.
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
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.
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
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
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
recommended to be included as part of a primary change request form are as
Change Requestor Name
Change Requestor Phone #
Name of Supervisor
Data Steward Indicator
Date Change Request Submitted
Requested Change Implementation Date
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.
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
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
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
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
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
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.
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
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
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.
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.
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
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.
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
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
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
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.
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/
Define the Objective and Scope for Change Management Completed.
CM Project Team
(Create Project Definition).
Establish and agree on a clear definition for the word Completed.
“Change” within the context of the AIS IT Infrastructure.
CM Project Team
Seek initial approval. Completed.
(Project Definition accepted). Sr. Management Team
Preliminary Requirements Analysis Completed.
CM Project Team
STEPS (Phase 2) NOTES/
Establish Implementation Team 1/31/2006
CM Project Team
Establish Change Team(s) and Define Charter(s). Minimize 1/31/2006
training, education and implementation time lines by
reusing some of the existing skills base.
(S)Elect Change Coordinator for each Change Team. 1/31/2006
(By default, the Change Advisory Board will be comprised Implementation Team
of a Change Coordinator from each Change Team). (With recommendations
from CM Project Team)
Adopt an official Change Policy. 2/28/2006
(Complete work started by CM Project Team). Change Advisory Board
Develop a Change Classification Matrix. 3/31/2006
(Complete work started by CM Project Team; the matrix Change Teams +
will be multi-dimensional). Implementation Team
Review existing CM practices in greater detail. Review 3/31/2006
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. Change Teams +
(See Appendix E for suggested review areas).
Document the transition from current change process 4/15/2006
format to any new format that is selected.
Change Teams +
Develop specifications for a Change Data Request form 4/30/2006
and a Change Data Repository.
Change Teams +
(Ensure request form and repository are in synch). Implementation Team
STEPS (Phase 2—continued) NOTES/
Determine appropriate change approval path(s) for each 4/30/2006
Change Teams +
(Explore Workflow approval path methodology; ensure Implementation Team
proxy approver capability).
Develop specifications for a new (Web-based) Change 4/30/2006
Change Teams +
Develop specifications for a change notification process. 4/30/2006
Change Teams +
Develop specifications for a “conflict resolution process” for 4/30/2006
prioritizing and scheduling changes.
Change Teams +
Develop specifications for change management reporting 4/30/2006
and monitoring functions.
Change Teams +
Define a change testing process (specification). 5/31/2006
Change Teams +
Establish a selection guideline for the evaluation and 6/30/2006
selection of tools based on the specifications developed.
Change Teams +
Evaluate potential ICMS software solutions. Decide how 7/31/2006
best to select any vendor that will provide assistance in the
evaluation process. Change Teams +
Implementation Team +
Select ICMS software solutions. As cost will be a major 8/31/2006
factor in the decision, an estimated cost for current change
processes should be provided for comparison. Change Teams +
Implementation Team +
(Make recommendation for build vs. purchase). Infrastructure
STEPS (Phase 3) NOTES/
FUTURE TASKS (Phases 4 - 6)
Purchase/Build and install ICMS software solutions. If TBD
purchased, ensure adequate skills transfer (education and
training) and on-going support is provided. Infrastructure and AIS
Document and get agreement on roles, responsibilities and TBD
Change Teams and AIS
Create any required business process interfaces that can TBD
be provided via the selected (automated) tools.
AIS Senior Management
(Reporting: frequency + content).
Announce availability of the new ICMS. TBD (estimate: 2Q07)
AIS Senior Management
Integrate ICMS solutions with Disaster Recovery Process TBD
(Phase 4: ICMS integration with LDRPS software—should Change Teams +
be a separate project). Implementation Team +
Infrastructure + DR Team
Implement Version Control / Release Level Process TBD
(Phase 5: Should be a separate project). Change Teams +
Implementation Team +
Integrate Problem and Asset/Configuration Management TBD
into the ICMS.
Change Teams +
(Phase 6: Should be a separate project). Implementation Team +
It is important to re-emphasize that the above implementation strategy can only
succeed if appropriate resources are allocated.
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
…3 8-hour periods
…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
Number of changes by group (i.e. area within AIS)
…Network Infrastructure & Data Security
…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
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
…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.
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
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
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
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.
Appendix D: Information Technology Infrastructure
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
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
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).
The Visible Ops Handbook: Starting ITIL in 4 Practical Steps
Strategies for Implementing Change
Planning to Implement Service Management (ordered/not received)
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:
Power teams (i.e. Change Approvers)
Current formal procedures
Current informal procedures
Current role descriptions
Existing organizational structure
Spreadsheets, databases and other repositories
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).
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
A formal policy needs to be developed for emergency changes; and it must
Risk assessment should be a high priority issue when defining levels of
All changes must be documented.
Existing change processes and change forms should be integrated into the
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
The new ICMS should be able to interface with the Disaster Recovery
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
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
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.
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
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
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
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
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
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
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
We need a Web-accessible central repository for all product installation
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.