Change management is defined in ITIL, COBIT, and other guides. These frameworks can provide a context for understanding change management.
Change management is a prerequisite for many of the ITIL processes. Change management allows other processes, such as configuration management and IT Service Continuity Management, to update their records as production changes.
The "business case" for change management cannot be made as easily in terms of costs, or return on investment. University IT departments must know what they want before they can justify pursuing change management.
| Attachment | Size |
|---|---|
| Service Acceptance Criteria FV1.doc | 41 KB |
| WFU IS First CAB Meeting.pdf | 202 KB |
| CAB Agenda Template.doc | 54.5 KB |
Change categorization is an important component of change management. This page assumes an understanding of the overall "change lifecycle" as defined in ITIL's change management process.
One of the activities in ITIL v2's "Change Management" process is "Change categorization" (section 8.5.4 of Service Support). This v2 activity is a component of ITIL v3's "Assess and evaluate change" activity (Service Transition section 4.2.6.4).
Categorization allows changes to be processed differently. For example, one type of change might need to be reviewed by the CIO, and another type might just need a local authority (such as a manager) to approve the change. Categorization can also ensure appropriate data, needed for subsequent activities and/or reporting, has been added to a request for change (RFC).
Categorization, however, includes several different dimensions of data. ITIL v2 explicitly recommends categorization based on impact and cost:
However, an organization may also want to categorize changes based on what is being changed. ITIL v3's change management process explains several types of changes, in table 4.3:
Arguably ITIL v3 is confusing the issue when it mentions project change proposals and user access requests, as project governance is otherwise frustratingly absent in the ITIL materials and user access requests are covered in another ITIL v3 process, "access management."
Finally, changes may need to be categorized based on why they are occurring. ITpreneurs' ITIL "Release and Control" practitioner training materials mention four change types on slide 22 of their change management training slides:
ITIL v3 expanded on the ITIL v2 concept of Configuration Management, creating a larger process called "Service Asset and Configuration Management."
"Knowledge management" is an ITIL process, first introduced in ITIL as of version 3. The scope of this process can be very broad, potentially including
The term knowledge management is used in different ways in other disciplines; it would probably be a good idea to define the term "knowledge management" carefully before using it.
ITIL v3 describes how information is processed through a "DIKW" flow:
These four phases describe the information itself. Educators might see a parallel to Bloom's Taxonomy, which describes the levels of comprehension:
(These levels are used in the ITIL v3 course syllabi.)
ITIL v3 also proposes the "SKMS"--Service Knowledge Management System--which could be considered the "holy grail" of ITIL v3 the way the CMDB was for ITIL v2. The SKMS would essentially contain all ITSM information.
"Knowledge management" is somewhat of a buzz phrase. The term is not IT-specific, so when talking about "knowledge management" at a University, other departments may have their own definitions.
Release and deployment management is very closely related to change management, and arguably a successor to a good change management program. Please make sure you understand change management before diving into release management.
Release and deployment management is about defining a lifecycle for certain types of changes (e.g. how changes to server operating systems are built, tested, and deployed), and it's about grouping changes together (e.g. all the changes for server operating systems occur at the same time).
For example, Unilever said in their 2007 itSMFusion presentation that their desktop changes are scheduled so that
This process makes it easy to understand how changes are applied to desktops, ensures that changes are tested, and ensures that time and resources are available for the changes. The testing group knows that if their desktop is messed up in the last week of a month, there is probably something wrong with the next load.
Often project management takes on a "release management" role of making sure that the schedule for production changes is understood, that changes are tested, etc. With a strong release management process, project management can trust their changes to release management and then release management can coordinate changes from multiple projects, and relieve some of the effort from project managers.
It is tempting to begin release management with software development projects, as release management defines a standard lifecycle and people are often familiar with their software development lifecycle. However, it's better to focus on areas where
These criteria could apply to your software development lifecycle, but more likely apply to other types of changes e.g. OS patches or vendor-provided application upgrades. You will get much more value for your effort if you start with problem areas, rather than trying to re-define your existing (and working) processes under the title "release management."
Release management is a good time to take care of the "under-the-radar" issues, that need to happen but don't get much attention, to build wins for release management.
"Release management" is not a tool issue. You don't buy a tool and suddenly have release management.
Your release management process needs to work especially well with your change management process.
Really long video from Cambridge about release management in open-source software: