An explanation of how Release, Change, Configuration, and Project Management work together to coordinate multiple implementations into test and production environments while reducing risk and business impact.

1. S T E V E N R AG S D AL E
ITIL Practitioner Release and
Control Review

2. Release and Control Overview
- an aviation comparison
 Release Management is the airplane pilot
 They handle the technical details of “landing” their assigned Release
 Change Management is the air traffic controller
 They see a holistic view of all releases and make sure each has the
proper documentation, “flight plan” and approval to “take-off” and
“land” while avoiding “collisions” on the “runway” and in the “air”.
 Configuration Management is the airline
 They maintain the timely and accurate information of what “planes”
are where, with which “passengers”, components, etc.
 Project Management is the co-pilot
 They navigate and guide the release and make sure everything is
done as planned.

3. Configuration Management
 Goal: Provide a logical model of the infrastructure or a service by
identifying, controlling, maintaining, and verifying the versions of Configuration
Items (CIs) in existence.
 Unlike traditional Asset Management, the CMDB maintains accurate and timely
information on:
 Hardware
 Software
 Documentation
 The relationships between the CIs
 This is the most important aspect of the CMDB but also the hardest to document and maintain.
 The CMDB is a “glorified library card catalog” and Configuration Management
is a passive process that enables all others.
 Should create Configuration Baselines on a regular and as needed basis

4. CMDB
 What scope is the right amount?
 If you have to create an RFC (Request For Change) for every
time you change a CI what level of detail do you want to make
a CI?
 A Desktop Keyboard
 A Line of Code
 A Sound Card
 Probably not, but yes for CIs such as:
 A Desktop or Laptop Computer
 A Code Module (ex. PD, WS, .scr files in Lawson)
 Project SDLC/SOX documentation!

5. Terms differences
 Verification vs. Audit
 Verification – informal check of data correctness
 Performed by everyone as they use the CMDB
 Audit – formal check for systemic issues with process or control
 Performed by internal or external audit teams
 Change Acceptance vs. Approval
 Acceptance is based up completeness and accuracy of the CR
 This is done by the Change Coordinators
 Approval is based upon the content (impact & resource
assessment) of the CR
 This is done by the Change Manager in addition to other IS and
Business Management in the CAB meetings or Executive Steering
Committee for Major changes (Projects)
 3 principal approvals required:
 Financial – cost benefit assessment
 Technical – feasible, sensible, and achievable
 Business – customers are agreeable with the proposed impact

6. Change Management
 Goal: To ensure that standardized methods and
procedures are used for efficient and prompt handling of
all changes to minimize the impact of change-related
incidents and improve day-to-day operations.
 Change Management is the guardian of the Production Environment!
 Garter reports that “65 – 85% of incidents are because of failed
changes”
 What is the value of your “yes” if you never say “no”.
 The key is to minimize risk exposure, impact &
disruption, and for every change to be successful at the
first attempt, saving the business money and time.

7. Change Management
 Change Models
 Major
 1%, requires Exec. Steering Committee approval
 Projects (Infrastructure, Software, or Process)
 Significant
 3%, requires CAB approval
 Changes that must take place during the maintenance window
 Minor
 16%, requires just Change Manager approval
 Changes that need to be approved for completeness
 Standard
 80%, pre-approved
 Follows an established path and is an accepted solution

8. The Change Advisory Board (CAB)
 Regularly scheduled meeting lead by the Change Manager
 Attendees:
 Customers affected by the change
 Representatives of each group in IS
 Representative from Contractors
 Will be composed according to Changes being considered
 Proposed Changes should be communicated before meeting
 Duties include:
 Review all significant CRs and determine their likely impact, risk,
implementation resources, and ongoing costs of the changes.
 Give an opinion on which changes should be authorized and participate
in scheduling.
 Be available for consultation for urgent changes (CAB/EC only)
 CAB Emergency Committee

9. CAB Meeting Agenda
 Minutes from the last meeting
 Minor changes approved/rejected since last meeting
 Failed changes, backed-out changes
 Closure Code: Unsuccessful, Successful with Problems, Rolled-back
 Emergency / Urgent changes
 Significant CRs to be assessed by CAB
 CRs that have been authorized, built, tested, and require
scheduling for implementation
 Projects going in soon
 Review of “open” changes - implemented but not closed
 If open longer than 1 month close “user unresponsive” and report to
Senior Management unless post implementation testing cannot be
done (i.e. year end changes)
 The Change Management process, successes and failures
 Findings from recent Production Implementation Review meetings
 Change Management KPI Reports

10. Release Management
 Goal: Take a holistic view of a change request to an IT
service, ensure that all aspects of a release, both
technical and non-technical, are considered together.
 Release is a verb – to implement
 Release is a noun – 2 or more bundled into a release
 Why:
 Bundle to make the best use of scarce resources – people, test
equipment, maintenance window
 To deliver related RFCs
 If part of the Release fails the whole thing is backed out!

11. Release Management - Scope
 Application programs developed in-house
 Lawson, Adobe Forms, .com, Web Services, Siebel, EDI, Lotus
Notes, Crystal Reports, Data Warehouse
 Externally developed software (including COTS as well
as customized packages)
 Catalyst, Remedy, Xelus, Info track (MRO), Mobius, Oracle
 Utility Software
 Supplier-provided systems software
 IBM AIX, SUN Solaris, MS Windows, Linux
 Hardware and hardware specifications
 Assembly instructions and documentation, including user
manuals

12. Release - Divisions
 Major software Releases and hardware upgrades:
 Large areas of new functionality and represents an IT project
of high risk and complexity
 Minor software Release and hardware upgrades:
 Small enhancements and fixes, some of which may have
already been issued as Emergency Fixes
 Work Package (PMO)
 Emergency software and hardware fixes
 Normally containing the corrections to a small number of
known problems which are affecting service delivery
 Urgent fix to restore day-to-day operations

13. Release Readiness?
 Go/no-go decision on:
 Operational ability of the service solution
 Readiness of operations and support staffs
 Completeness of the release-to-production plan
 Tested back-out plan
 Assessment of the impacts on other systems
 Hardware and software completeness

14. Critical Success Factors
 Configuration Management
 Control of IT assets
 Support the delivery of quality IT services
 Economic Service Provision
 Support Integration and interfacing to all other ITSM processes
 Change Management
 A repeatable process for making changes
 Make Changes quickly and accurately (business driven needs)
 Protect services when making changes
 Deliver process efficiency and effectiveness benefits
 Release Management
 Better quality software and hardware
 A repeatable process for rolling out software & hardware
Releases
 Implement Releases swiftly (business driven needs) and
accurately

15. Roles and Responsibilities
 Configuration Manager
 Configuration Librarian
 Change Manager
 Change Coordinator
 CAB Recorder
 Release Manager
 Release Coordinator