ITIL V3 - What's New?

So here are the five new core books. In V3, ITIL remains a descriptive best-practice framework, but it covers a lot more ground then V2, and the evolved part focuses mostly on IT & business integration.

New processes and functions aim to form a tight connection between business and IT organisation, anticipating business, technology and regulations changes in last 10 years since the last ITIL update.



Five essential core books represent basic ITIL Service Lifecycle elements:

• Service Strategy: Creating the set of services that help achieve business objectives.
• Service Design: Designing services, from technical and business perspective.
• Service Transition: How to change live production infrastructure, implementing the needed services.
• Service Operation: Day-to-day IT business, operating. A place to start if you are new to ITIL.
• Continual Service Improvement: Evaluating and improving services in support of business goals.

Processes are nicely reshuffled and strategically grouped to ensure a better support for business objectives. Some of the existing processes are changed or split in more sub-processes, and several new processes and functions are added.
Example: due to development of web and other ITC technologies, the impact and role of self-help in Service Operation is much more significant lately. As a result, a new process - Request Fulfillment spinned-off from Service Desk function. Also, Problem Management process developed in a more streamlined fashion, removing the problem/error control inconsistencies. A few of the other existing processes are reshaped in a similar way.
First impression is that the material is somewhat better organised, with a more transparent structure and refreshing hints, tips, real life examples, even anecdotes! I discovered that with V3 I need to read 10 pages before I fall asleep, as opposed to V2 where 1-2 pages threw me in a narcoleptic seizure.
Reading the books, one notices a tad of presctiptiveness here and there, and this trend is allegedly going to continue with complementary add-on material which will connect and map ITIL with different methodologies, market sectors and technologies.
V3 is here, and summer vacations are here also, so we will all have some time to digest the new material and see what happens next. I wish you all happy holidays!

ITIL Service Support Process Interaction

ITIL Service Support Process Interaction Diagram

I have been putting ITIL V2 Service Support info here for some time, sabotaging the fact that V3 is out there for more then a month. In the meantime I visited a local ITSMF conference with ITIL V3 presented by Vernon Lloyd and David Wheeldon. I got the books with nautilus, peas, starfish X-ray design covers. They are stashed near my bedpost, efficiently putting me to sleep almost every night for some time. Besides, much is said about V3 recently on the Net and I was constantly lacking time for V3, since I had to prepare for my ITIL Service Manager exam.

Now I will have some spare time to dedicate to V3, and I will put here my observations in near future, while I am still fresh with ITIL ITSM data.



To wrap this Service Support series of articles I am giving you my CMAP diagram of process interaction, very simplified and adjusted to my level of complexity tolerance.

Mind mapping is nice and all, it works for some people more then for the others, but this little free tool is a great convenience in process and knowledge mapping. I could do this in MS Visio, but I tend to keep info available to wide audience, so please, if you want this map, drop me a comment. Enjoy.

ITIL Release Management Quick Reference

"The release of atom power has changed everything except our way of thinking...the solution to this problem lies in the heart of mankind. If only I had known, I should have become a watchmaker.” - Albert Einstein

Release Management is an ITIL process that on first sight looks like a logical part of Change Management, to most heads. As we consider the number of changes and their possible impact in business organizations, it becomes clear where this process came from: practical need to coordinate things.

It has a lot of goals/objectives, but it is not an overly complicated process. It just takes care that all changes are implemented in accordance with other ITSM processes and aligned with business needs.

Here are the main elements of Release Management to have in mind:

Goals

• To plan and manage releases to the customer successfully
• To consider all technical and non-technical aspect of a release by taking a holistic view of implementing changes to IT services

Objectives

• To plan the successful roll-out of software and related hardware
• To design and implement efficient procedures for the distribution and installation of changes to IT systems
• To communicate and manage the expectations of the customer
• To ensure implementations are traceable, secure and that only correct, authorized and tested version are installed
• To agree the exact content and roll-out plan for the release, trough liaison with Change Management.
• To ensure that master copies of all software are secure and that the CMDB is updated
• To ensure that all hardware being rolled out or changed is secure and traceable, using the service of configuration management.

Inputs

• Release definition
• Release Plans, Test plans & Acceptance Criteria
• Copies of Installation media and instructions

Activities

• Release Policy and planning
• Release design, build and configuration
• Release acceptance, sign-off for implementation
• Roll out Planning
• Extensive Testing
• Communication, preparation and training
• HW and SW audit prior to Implementation of Change
• Installation of new or upgraded SW
• Storage of Controlled SW
• Release, Distribution and the Installation of SW

Outputs

• Detailed Release & Build instructions
• Purchase orders, licences & warranties for 3rd party HW and SW
• Automated installation scripts and test plans
• Master copies of install. Media and install. Instructions (stored in DSL)
• Back-out procedures
• Tested Install procedures, Release Components, backout procedures
• Known errors to be carried into live env.

Benefits

• Ability to cope with higher frequency of releases without sacrificing IT service quality
  Greater success rate of releases
• Consistency of releases
• Minimal disruption to service
• Known quality of hardware and software in live use
• Stability of test and live environment
• Ability to set expectation with publication of an advance release Schedule
• Reduction in Incidents caused by poor release
• Audit trail of changes to the live environment
• Reduced risk of unauthorized, illegal or malicious software
• Reduced time to release and fewer delays
• Fewer Releases to be implemented

Possible Problems

• Resistance from staff
• Circumvention of procedures may be attempted
• Staff may keep using emergency fixes
• Reluctance to carry out a controlled build
• New versions are not installed on time at remote locations
• Unclear ownership and responsibilities
• Release management procedures seen as cumbersome and expensive
• Unavailable resources for adequate testing
• Unavailable machine and network resources
• A lack of understanding of the release
• Staff may be reluctant to back out from a release
• Poor testing environments and procedures may exist

Roles and Responsibilities
Roles and responsibilities of Release Management are divided between Change, Release and Test Managers

• Roles defined centrally as required for specific Releases
• Roles "mixed" depending on package, urgency, project…
• ARCI Matrix (i.e. from RFC-Assessment-development-Testing-Implementing-Audit&Review Closure-CMDB update)

Key Performance Indicators

• Number of major Releases rolled out into production
• Average duration of Rollouts from clearance until completion
• Number of Release Backouts
• Number of incidents caused by new Releases
• Proportion of Releases finalized within the agreed schedule
• Work effort for the Rollout of new Releases
• Proportion of new automatically distributed Releases

Change Management Quick Reference

"It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change." -Author unknown, commonly misattributed to Charles Darwin.

"It is not necessary to change. Survival is not mandatory." -W. Edwards Deming.

"The only man I know who behaves sensibly is my tailor; he takes my measurements anew each time he sees me. The rest go on with their old measurements and expect me to fit them." -George Bernard Shaw.

Change Management (CM) is the most complex process in Service Support. It's
importance resides on a fact that over 80% of incidents emerge from performed changes. Therefore changes should be managed. Most of the ITIL compliancy projects fail at CM. It requires a high level of collective discipline, skills and mindset.

There is a connection of Change with all other ITSM disciplines, but especially with Release, Configuration and Capacity Management.
For your convenience, here are Change Management quick reference data I gathered for my ITIL Service Manager exam:



Definitions:

• RFC - Request For Change: can be triggered from different sources: Incident/Problem resolution, introduction/upgrade/removal of the CI...
• FSC - Forward Schedule of Changes: details of all the Changes approved for implementation and their proposed implementation dates
• PSA - Projected Service Availability: contains details of Changes to agreed SLAs and service availability because of the currently planned FSC
• CAB - Change Advisory Board: a body that approves Changes and assists Change Management in the assessment and prioritization of changes, composed of major stakeholders impacted by the change and technical staff responsible for tech. implementation
• CAB/EC - Change Advisory Board / Emergency Comitee: a smaller body with authority to make emergency decisions in case of Urgent Changes
• CMDB - Configuration Management Database

Goals

• To minimize the adverse impact of change upon service quality
• To ensure standard methods and procedures are used for efficient and prompt handling of all changes
• To assess the potential benefits of change to the organization against the risk and associated costs to the organization

Picture: Change Management Mind Map


Process

• raising and recording Changes
• assessing the impact, cost, benefits and risk of Changes
• developing the business justification and obtaining approval
• management and co-ordination of Change implementation
• monitoring and reporting on the implementation
• closing and reviewing the Change requests

Inputs

• RFCs
• CMDB
• FSC - Forward Schedule of Changes

Activities

• Initiating and logging
• Initial filtering
• Allocating initial priority
• Categorization
• Assessing impact and resource
• Authorizing and approving
• Scheduling
• Building
• Testing
• Implementing
• Reviewing
• Management reporting on Change Management quality and operations

Outputs

• FSC
• RFCs
• CAB minutes and actions
• Change Management Reports

Picture 1: BASIC Change Management Process


Benefits

• Less adverse impact of changes on the quality of IT services and SLA
• A better assessment of the cost of proposed changes, before it is incurred
• A reduction in the number of changes that have to be backed-out, but an ability to be able to do this more easily
• An ability to absorb a higher level of change without difficulty
• Increased visibility and communication of changes to both business and service support staff
• Improved risk assessment
• Improved Problem and Availability mgt. trough the use of valuable management information relating to changes
• Increased productivity of key staff as less need for diversion from planned duties to implement urgent changes or back our erroneous changes

Possible Problems

• Implementing on over bureaucratic process
• Attempt to bypass the process
• Paper based system - bottleneck
• Cultural difficulties - getting buy-in
• Contracts and third parties
• Scope of change is too wide
• Ownership of impact systems is unclear
• Lack of Configuration Management
• Inaccurate configuration details leading to poor impact assessment
• Lack of management commitment
• Poor synchronization of upgrades between platforms and across locations
• Back-out procedures are missing or not tested
• Handling of urgent changes
• Progressing RFC is too manually intensive
• Complex distributed or mobile infrastructure
• Time-scales (too ambitious)
• Lack of resources (people, products)

Picture 2: STANDARD Change Management Process
Responsibilities
Change Manager:

• Receive, log and allocate priority to all RFCs. Rejects inappropriate RFCs
• Table RFCs for CAB meetings
• Decides meeting participants according to RFC nature
• Convene Urgent CAB or CAB/EC meetings for all URGENT RFCs
• Chair ALL CAB meetings
• Authorize acceptable Changes (according to CAB decisions)
• Issue FSC via Service Desk
• Liaise with all parties to coordinate change building, testing and implementation
• Update Change log with progress
• Review implemented changes
• Review all outstanding RFCs waiting consideration or action
• Analyze Change records to identify trends or apparent problems that can occur
• Close RFCs
• Management reporting

CAB:

• Review all submitted RFCs. As appropriate, determine and provide details of their likely impact, the implementation resources, and the ongoing costs of all Changes.
• Attend all relevant CAB or CAB/EC meetings. Consider all Changes on the agenda and give an opinion on which Changes should be authorized. Participate in the scheduling of all Changes.
• (CAB/EC only). Be available for consultation should an urgent Change be required.
• Provide advice to Change Management on aspects of proposed urgent Changes.

Picture 3: URGENT Change Management Process


Key Performance Indicators
Controlling Changes

• Number of RFCs processed
• Number of RFCs rejected
• Number of unauthorized changes detected
• Number of RFCs implemented on schedule
• Number of RFCs requiring reschedules

Making Quick and Accurate Changes Based On Business Priorities

• Number of RFCs marked as URGENT
• Number of RFCs not tested prior to implementation
• Number of RFCs that failed
• Number of RFCs without business case
• Number of RFCs bypassing CAB or CAB/EC

Protecting Services When making Changes

• Number of high Severity incidents caused by RFC implementation
• Number of other incidents caused by RFC implementation
• Number of RFCs without a backup strategy