A Brief History of ITIL

I have looked arround the web a little and was bored with the general ITIL history articles found on the web. There are a few inconsistencies and interesting myths circling around, like the one on the Falklands war and possible general war threat with Argentina, which are denied by the authors of V1.
The fact that Mrs. Thatcher came to power in 1979. and that ICT budget of UK government exceeded 8 bil. UK pounds was probably one of initiators of GITMM (or GITIMM, not sure).

So, here is a short list of important milestones:

1972: IBM starts research on quality service delivery called Information Systems Management Architecture (ISMA).

1980: IBM publishes Volume I of the IBM Management series titled "A management System for the Information Business", first public edition of ISMA.

1986: CCTA authorizes a program to develop a common set of operational guidance with the objective of increasing efficiencies in Government IT.

1988: "Government Infrastructure Management Method (GITMM)", is formalized and issued as 'guidelines' for Government IT operations in the UK focused on Service Level Management. Same year, the development team was expanded and work continued on Cost, Capacity, and Availability.

1989: GITMM title is inadequate. It is not a method, (last M), and it should lose its G letter in order to be marketable out of government. Renamed to ITIL.

1989: First 'ITIL' book published, Service Level Management, then Help Desk (incorporating the concepts of Incident Management), Contingency Planning, and Change Management. Books had 50-70 pages.

1990: Problem Management, Configuration Management and Cost Management for IT Services published.

1991: Published - Software Control & Distribution, on 89 pages.

1992: Availability Management, 69 pages.

1996: (July) First ITIL Service Manager class delivered in US by US company, ITSMI, 16 attended, 10 candidates, nine passes, one distinction, first US company authorized as an ITIL accredited course provider - ITSMI.

1997: Customer focused update to the Service Level Management book, 106 pages.

1997: ITIMF legally becomes what we know today as the IT Service Management Forum (itSMF UK).

2000: Service Support V2 published, 306 pages.

2001: Service Delivery V2 published, 376 pages.

2001: CCTA became a part of the Office of Government Commerce (OGC)

2002: Application Management, 158 pages, Planning to Implement IT Service Management, 208 pages and ICT Infrastructure Management, 283 pages, published.

2003: Software Asset Management, 146 pages, published .

2004: Business Perspective: The IS View on Delivering Services to the Business, published, 180 pages.

2006: (June) ITIL Glossary V2 published

2006: (June) APM Group Limited announced as preferred bidder of ITIL accreditation & certification program, over the itSMF International (expectant winner)

2007: (May) ITIL V3 five core books published.

2011: (July) ITIL 2011 update published.

Let's analyse this timeline a bit:

ITIL V1 was rather similar to IBM's ISMA, especially in support/delivery domain. Core ITIL V2 books did not differ much from ITIL V1. Only a few processes were altered slightly, but the focus and perspective was pretty much unchanged. And this process lasted for some 20 years.

ITIL V3 approximately doubled the scope, almost tripled the number of processes and functions and introduced a few new dimensions and perspectives. We have the first set of core books now, but a lot of time will be needed to develop all the complementary books, to groom and mature the training materials and to polish best implementation practices.

ITIL 2011 books grew 57% in weight and 46% in number of pages due to rewrite and redesign (larger font).

ITIL V2 Mind Maps Free Download

I have took the liberty of posting my ITIL Service Support and Service Delivery mind maps in .mmap form. I have created these while preparing for my ITIL Service Manager exam.
They are simple reference documents with basic bullets per process, but I hope you can use it and upgrade them if you wish while you study.
Documents will be on eSnips for the first time, until I migrate this blog to another domain.
Links to documents can be found in the upper left part of the homepage.
Soon I will post some of my V3 maps and graphs in the same place.

ITIL V3 And The Vacuum

I had a brutally long vacation, as you have maybe noticed from the lack of posts here.

Most of the time I did nothing but enjoyed the sun and the sea, and of course, long reading sessions of new V3 ITIL books. First week I read Strategy, Design and Transition books cover to cover, and couldn't remember much after the first reading. Books are NOT dull and boring like the previous version. Most of the material is well written, but the perspective is new and the flavour is of an acquired taste, especially for an old IT dog accustomed to years of process-based approach to Services. So I read some more and parts of it started clicking in place.

A funny thing happened with this ITIL V3 rollout. Seems like things are getting worse before they will get better. Previous V2 story got a huge and powerful dimension with this new service lifecycle aspect. The result is a vacuum window for all animals in the ITIL food chain. Certification organizations and education companies are waiting for new sylabusses and exams and customers are starving for new trainings. OK, maybe good consulatnts can fish somewhat more in these times of uncertainty.

Best we can do is to try to stay positive and wait for things to happen, hoping for the best.

New Qualification Scheme with nice colourfull explanations and doubtful scoring is published, and now we wait for the sylabusses.

ITIL V3 Foundation exams are out. From what I can see, they last for three days instead of the previous two. Judging by the fact that the scope at least doubled in size, and that Foundation level should have 90% pass rate, I doubt that Foundation material will cover anything more then a well described Glossary. Which is fine by me, at least it will make people read some of the books, and pull their heads from the same old process-based holes in the sand (takes one to know one!).

Nice thing to see is that practitioner layers of qualification scheme are finely granulated to enable a phased approach of candidadtes according to their professional preferences. Score enough points, and move up.

And the whole Scheme has an additional vertical layer. Which is OK, given the size of the newly introduced dimensions.

What bothers me most at a present state: it looks that the change of bottom->top to top->bottom approach has lost it's steam somewhere in the middle, and presently there is a missing link to connect old process-based and the new Service Lifecycle perspective. There is no place with systematically defined new processes and modifications to old ones. It would be the starting point for the new people in the business, trying to build some foundations and systematically start to introduce some order to their hectic IT operations. When you start, you do it from the ground up, you do not build things roof-to-basement. Or am I wrong? What do these people have? A set of five books which are difficult to sell to their management. I'm not worried, it's just that this void, the vacuum window will last for some time, and then things are going to click in place eventually.

All we have to do is wait a while. In the meantime, we could do something, like request the additional complementary material. Or even help to create it. Are the itSMF chapters good candidates for the job? What do you think?

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
  

MS SC Service Manager Beta 1 is Here

Is Microsoft a serious new player in Service Management field?

I had the pleasure of downloading and installing Beta 1 Microsoft System Center Service Manager last week. I am not the fan of MS, or any other tools vendor, so this post is not an add. Since I have some experience in ITSM and have seen, implemented and developed some tools, I have something to say here.

Service Manager is slow and forms are ugly. It is slow because it is in Beta 1 and running on sub-optimal code. Forms are ugly because it is in Beta 1, they are very simple unpolished InfoPath forms.

Other then that, I look forward to this product, because it seems to me that it is based on firm theory (ITIL/MOF/DSI), relies on mature Microsoft technologies (SQL Server, SharePoint, .Net, Office) and it will give a high level of integration with other System Center products, like Ops Manager and Configuration Manager.

Console resembles the Operations Manager 2007 Outlook-like console, so short learning curve and quick adoption is expected.

Functionality is kept mostly in Solution Packs, similar to Management Packs in Ops manager. So everything, from forms, workflows, repots, data models etc is in a solution pack. For now, Incident Management and Change Management solution packs are available, and a part of a future Asset Management solution pack. Reporting is performed on MS SQL Server Reporting Services. Most of the forms in all processes can be customized, fields added, data model extended.

Incident Management is planned to be ITIL compliant out of the box, so there are lot of customizing parameters available. Queues, drop-down values, locations, org. structure etc.

Change Management is also ITIL based, and seems decently engineered. As I said, forms are a bit slow, but in Beta 1 that should be expected.

Asset Management module is implemented for now as a simple inventory, a container for the connected SMS sync data.

Reporting is rudimental for now.

In Beta 1 there are only two connectors: AD and SMS. So one can import users from AD and assets from SMS.

Customer Portal is on SharePoint 2007 and it looks very sexy and promissing. Sincerely, one of the best-looking customer portals I have seen.

Beta 2 is planned for the 3Q2007. It will have improved Incident and Change Management solution packs and a functional Asset Management. Additional connectors for Ops Manager and Configuration Manager will be available. Also, larger set of reports.

This version satisfied my expectations, and I look forward to Beta 2. Seems to me that Service Manager has potential to be a very serious competition to HP Open View Service Desk. As I said earlier, good for us ;-)

CMDB - What You Need To Know

"Take care of the luxuries, and the necessities will take care of themselves." -- Dorothy Parker, an American writer and poet

Much is said about Configuration Management Database in IT information circles and literature. More or less, everyone agrees that CMDB is some kind of hub of all ITSM processes, but opinions differ on the scale of it's importance. From "nice to have because ITIL says so" to "first thing you have to do, without it nothing makes sense". Well, I am with this second extreme bunch.

ITIL is full of details and descriptions, but without a direct prescription how things should be done. Data model, relations, APIs? I don't blame them, technology is moving fast and things that will be possible tomorrow are imaginable by fewer and fewer people, so this vagueness in ITIL is given with a good measure of direct guidelines and freedom of interpolation. After all, CMDB became a kind of religion, even better, a Loch Ness monster parallel story: everyone is talking about it, and a very few people witnessed it. To some extent, one can agree with IT Skeptic that it can't be done by definition of Configuration Management goal:

"account for all the IT assets and configurations within the organization and its services"

ALL IT assets? What have you been smoking lately? There is a sniff of inconsistency here, since ITIL also talks about setting the level of CI control. So, what is it, ALL or SOME assets? Mouse, keyboard and web camera, or my precious USB mug heater, are they assets? Of course, we can give a better eye to this def, and read it backwards. ITIL is business oriented, and makes an (however large, still feeble) attempt to put a CUSTOMER in focus of poor over-worked sex depraved IT people. Not an easy task.

ITIL focuses on introducing order in IT, as a function of serving BUSINESS. ITIL mentions ALL assets, but in this context ALL means "as much as you irresponsible people can manage, and focus to those that are important for the business services to the ladies in the Accounting dept, or whatever dept. you signed your SLA with, without real understanding what SLA really means."

Every IT organization starting to deal with services quickly learns that it is not about Service Desk, Incident or Problem Management. It is WHAT you have, WHERE is it, WHO is responsible, HOW it works, WHEN is it going to die, and in WHICH way it supports our business. And approximately in that order. To every sensible IT guy it is obvious that CMDB can't be done, but that's something we HAVE to try to do. 30% is infinitely better then nothing, you can live with 70% and prosper for a long time. Take care of the luxuries first, cover the assets most important for your services, other CIs will fall into place with time and effort. A large US pharmaceutical company that implemented a new NW discovery tool found out that they have some 10.000 network assets more then they knew about. Have they survived somehow before that discovery? Of course. Have they found valuable resources and knowledge about their infrastructure that will help them be more agile and produce better decisions in the future? You bet.

Another thing. ITIL is IT oriented, and it covers basic best practices of IT organizations. Implementing ITIL is a first step in introducing organized structure to IT from bottom end, base of the pyramid. Above it, on the road to better understanding of business, stand methodologies which are not exclusively IT oriented, and they serve to connect IT to business even more, like BSC, SOX, COBIT, various project, work and performance management technologies. ITIL's task is to introduce first enablers of customer satisfaction. ITIL asks from IT to first form knowledge of their own business (CMDB) and then agree with Business on the best way to support it (SLM).

Views on CMDB and CI relations

I will discuss SLM and SLA later, and importance of Service Catalogs. For now, let me point out the evolution of structured thought: CMDB enables all 10 ITSM processes. It contains crucial information on CIs. Out of that info we start when we define basic components and IT services. Only then we are able to introduce the IT to Business and really listen to it's requests. That's why the Service Catalog resides in CMDB, or ON the CMDB, because it comes from the opposite direction. CMDB thinks bottom-up, and Service is defined top-to-bottom. So it is a crucial link from CEO to your network switch, from IT to Business. That's why in implementing ITIL, a common sense is to start with Service Desk, Configuration and Incident Management, and Service Level Management in parallel.

A number of possible problems can occur in CMDB life, aside from the obvious and mentioned in ITIL Blue Book. Integration with other ITSM tools is a very important one. I have seen some IT companies implement a stand-alone CMDB. Not sure what is the purpose of that. Also, CMDB deals with the data that naturally or historically reside in other applications, like ERP, HRM, Document Management, Asset Management... There is always a grey area or overlapping as some data wants to live in more then one place.

Main rule is: if there is a legal, financial, technical or strong cultural reason for a type of data to be referent in other systems, then periodical mirroring of data is performed (hourly or daily) to CMDB. Some data will be synchronized inbound to CMDB, (ERP people are particularly sensitive to their data) and some will be synchronized both ways, like contact data (mail, phone etc.) to and from Human Resources Management application. Some data will eventually be synched outbound, to Asset Management application for example.

A lot of it can go wrong in CMDB implementation. But, based on all the above and some more, having a CMDB conforming to ITIL recommendations, common sense and your business needs is a one of the hardest and most rewarded projects that an IT can perform.