ITIL Major Incident - All you want to know

What is a Major Incident in ITIL? What are the roles and responsibilities? How to avoid common mistakes? What to do After the Resolution?

Trust me, I know what I'm doing!
Sledge Hammer

What is a Major Incident?
Definition of a Major Incident has to be clear to every employee in Service Support. Therefore it has to be clearly described in a separate document, Major Incident Procedure.

What makes a Major Incident? It is usually defined by the impact outage has or could have on customer’s business process. Also, it may be determined by priority of the incident or by its urgency.

How come that the impact isn’t allways the only factor in defining the Major incident? For example, an incident of high impact can be resolved by Service Desk thru a simple resolution procedure, like switch resetting after network down event, or connecting a backup provider after internet down event.

Both examples are definitely high impact but we don’t have to recruit a bunch of higher level people on it just yet. We just have to have in mind that they are Priority 1 and they have to be resolved ASAP. In case they can’t be resolved by standard procedure, THEN they can be marked Major and handled with appropriate procedure and policy. That’s why most leading Incident Management tools on the market have a separate checkbox Major or Hot incident.

This was all theory. In practice, to simplify the procedure and make it easier to Service Desk staff, this is what I usually advise: all priority 1 incidents are Major Incidents, if they are not exceptions. Exceptions can be easily defined for particular customers, contracts and incident categories. For example: Major incidents are all Priority 1 incidents except cash register tickets, which are urgent but can be fixed by technicians, no need to involve for more important people. Or: all categories except end user incidents. Simple.

Major Incident Team

OK, now we have determined it’s a Major Incident. What next? We establish a Major Incident Team. Members are:

• Service Desk Manager – he will be responsible for communication with resolution team and timely reporting to the customer
• Incident Manager – in reasonable service organizations Incident Manager is usually also the Service Desk Manager. If not, then these two have to work closely together.
• Major Incident Manager: a frequent mistake is to promote Incident or Service Desk Manager into Major Incident Manager. This doesn’t have to, but can cause some serious conflicts of interests: he has to survive somewhere between Incident Management, Problem Management, Business Management and the customer.
  Major Incident Manager has to be a liaison between all internal parties involved, also acquainted well to technical aspects of the outage. So he will often be recruited between people formerly engaged in a project, or those involved in service catalogue definition.
• Problem Manager: remember him? He will be most helpful here in investigative phase, towards closure phase, and a life saver in post mortem reporting. Better keep him on our side. Mind you, Major Incident is still an incident, but usually has some underlying cause which will be recognized as a Problem. Hence Incident and Problem Manager have to work closely here, each with his own goal in mind (service restoration vs. underlying cause).
• Other members of Major Incident Team: representatives of all people involved, impacted users, competent technical staff, vendors... Good practice would be to choose people here the same way you would choose ECAB (Emergency Change Advisory Board) members. There is always a chance that you will be implementing an Emergency Change during a Major Incident resolution process.

Resolution Process

Major Incident resolution works on tight SLA parameters. Service Desk takes care of them. Also, ticket updates and frequent feedback to customers is performed by Service Desk. Remember, customer hates to be kept in the dark, even if news are bad (no progress) they must be updated frequently.

Major Incident Procedure has to define the escalation policy in case of SLA breech. Usually the incident is escalated vertically to higher level IT / Business management and to vendors of services/equipment underpinning the service.

After the battle

Upon the resolution, Incident Management Team stays “on call” and monitors the service for the period defined by Major Incident Manager. He also schedules a short team meeting for the next day.

Incident Review is performed on this meeting, points for improvement and lessons learned are defined and Post Mortem Major Incident Report is created.

Incident Manager sends the report to the customer.

I have prepared for you a template for Major Incident Report, free for download here.

Related posts:

Incident Management Elements
Key elements of Incident management.

Incident Management Mind Map
Download the incident management mind map.

All About Incident Classification

How to deal with incident categories.

What Everyone Should Know About Incident Priority

Incident prioritization in ITIL.

Hope this helps. Have a nice day!

Customer Satisfaction Survey: What Methods To Use?

How to gather customer satisfaction data? What methods are there? What ITIL says? What methods will work for you?

USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population.
David Letterman
 
In my last post I spoke about Customer Satisfaction. OK, but how to gather data? How to interview customers? How to get the best results in surveys and help educate the customer about the proces?
Here I give you a list of basic ITIL methods for gathering customer satisfaction data and my coments of its worth in my company. Mind you, we are in Managed Service business, so my grades are biased.

If you are a small IT in  government agency or an IT in Airline company, you may look for different values. Still, this will give you an idea.

Customer Satisfaction

After-Call Survey

Callers are asked to remain on the phone after the call and then asked to rate the service they were provided.

This method requires that you have some kind of telephony automation like Interactive Voice Response (IVR). The thing with this method is, however you set the system it will often be despised by the customer. Most of the people don’t like to hear recorded messages and even more people hate moving down the menu tree with phone keyboard. Outcome? Only extremes: customer which are very satisfied and wish to reward an agent by giving him good grades or, more often, a very pissed off customer who will go out of his way to express his low level of satisfaction.

Call Center organizations are doomed to use this technology since phonecalls are the only way of communicating with the customer. In ITSM there are usually more ways to talk to customer.

My worth: 1/5

Mail Surveys
We never considered sending mail interviews to customers as an option. Not in this century at least. What kind od IT-related person would fill the received paper form and send it back to us? Do we need a feedback from this kind of person? No, thanks.

With e-mail it's maybe slightly better. We used to have a ServiceDesk application which would send an automated notification on incident resolve event, asking the customer contact to reply in an email grading their satisfaction with speed and quality of resolution by grades 1 to 5. So lame. Response percentage of 0,05% was enough to pacify our ISO9001 auditor but it was next to worthless to us otherwise. One good thing was that receiving a small number of answers in an unstructured text email made the result processing much easier :-)

My worth: 1.5/5

Group Interviews

In this method, customers should be gathered in small groups and interviewed together. This can maybe be somewhat useful in a group of people working together, even then their answers will be biased and dependent. Possible value I see in this one is that they will help to develop communication between customers of different knowledge levels and enhance collective process knowledge.

In my organization we try to keep different SLA customers as far from each other as possible. We do not conduct group interviews but we do organize ITSM workshops here and there for our customers, feedback is usually very good.

My worth: 2/5

Phone Surveys
Some time after the interaction with Service Desk, an independent agent calls the customer.

You are in the middle of your monthly report, juggling a database and three spreadsheets, and some guy calls you to grade your experience with Service Desk from ten days ago? You will brush him off. OK, maybe not the first time, but the next, for sure.

So, if you want to get the results with this method, you need trained people with strong communication skills and good opening lines. Also, a good idea is not to have surveys for all calls, to let the customer rest from you periodically. If they anticipate your call, they start thinking up good excuses to brush you off. Surprise them periodically.

My worth: 2/5

Personal interviews

Surveying person is usually Incident Manager or Service Desk manager, while the Customer representative is a person responsible for SLA on their side. These can be contact persons on Major incidents after the post mortem reporting, but that’s another story and this should be defined in Major incident procedure.

These interviews are usually periodic and should be conducted at least annually (usually they are, during a contract renewal), but more preferably on quarterly basis. During these, the two parties communicate customer needs and help focusing Service Support towards things important to customer. So the questions in a survey should be aligned with Service Desk and Incident Management KPIs.

These are of great value to us.

My worth: 4/5

Online Surveys

We worked with several Service Desk automation tools, different vendors. In the end, we developed a Web application which enables us to send different surveys to our customers. They can be Ticket related, periodical or Ad Hoc surveys with predefine templates of multiple choice and freeform answers. We like it so much that we host it to other departments of our company. And we do not sell it, it’s that good :-)

Customers fill it in their own convenience (ok, we sometimes call and beg them to fill surveys), and after they submit the form they are automatically in the report.

Web-based surveys are a life-saver to us.
My worth: 5/5


Other Methods
Blogs, tweets, wikis, forum discussions and chats are all nice to have and, if maintained well, they will influence customer experience positively.

However, it is next to impossible to mine a structured measurement of customer satisfaction out of them, and they shouldn’t be used for that purpose.


Additional About Surveys

Scoring
It will be best to define simple questions with multiple choice number ratings. How many different grades? For fine gradation in longer interviews we use grades 1-10. For faster, ticket-focused surveys we opted for a coarser gradation. We used 1-5 for a long time, but a lot of the grades were distributed to 1, 5 and 3. Eliminating the middle value and shifting to 1-4 made our customers think more. We still use (1-4) system for most surveys and we are satisfied with it.

In addition, it is often nice to put an optional comment field under every question. Doesn’t cost much, and sometimes customers leave very useful info there.

How many questions?
You certainly don’t want to scare of the customer with a bunch of questions. OK, annual interviews can be longer, and internal ITIL/ISO20000 audits and assessments can gave a gazillion questions, but survey on incident performance can have only one (how satisfied are you?), ideally three, or maximum five multiple choice questions. You fish for quantity here.

Anonymous or named?
Some customers will answer an anonymous survey rather then named. Well, their problem. This is one case where customer is not always right. You want to know who is satisfied, who is not, so you can decide on your further actions.


Related posts:

Customer Satisfaction in ITIL Service Management: Do You Get It?
Elementary facts about ITSM Customer Satisfaction - How bad do we need it in IT Service Management? Where is it mentioned and where is it dealt with in ITIL V3? How do we manage it in real life?

Customer Satisfaction in ITIL Service Management: Do You Get It?

Customer Satisfaction:  How bad do we need it in IT Service Management? Where is it mentioned and where is it dealt with in ITIL V3? How do we manage it in real life?

- I Can't Get No...
- I'd rather be dead than singing "Satisfaction" when I'm forty-five.  
  Mick Jagger

Customer Satisfaction is very important. One of the main ITIL highs is to put a customer in focus. It is usually done by finding ways to raise the level of customer satisfaction. Often by creating a common language for better communication between the Business and IT.

Implicit, customer satisfaction is mentioned in all ITIL processes and functions. Explicit, there are parts of ITIL where we really take care of it. Where is it?


SERVICE STRATEGY
In Strategy stage of ITIL Service Lifecycle we are talking generally about opportunities, markets, possible services, where we are, where do we want to be. Here is where we firstly define the level of satisfaction we want to achieve. New people in this field think that a customer satisfaction should be as high as possible. Sorry but that's not the case. If customer is super satisfied it often means that we are over delivering, and he gets more then he paid for.

PERCEPTION
Satisfaction is about PERCEPTION. So, it is not about real objective quality of service, it is about how customer sees that quality. There are cases when a customer sees the service much better than it is, and also, sometimes the service is perceived much worse than it is in reality, usually due to bad communication, or a few isolated cases that gained higher visibility.

Customer interacts with service and compares its quality. To what? Not necessarily to a previous or existing service provider service, but always to his own EXPECTATIONS. That's why

Customer satisfaction =  Perception - Expectation

And our life depends on staying on positive side of this equation.


SERVICE DESIGN
Design is a phase where we define a new service. In the end of design phase we know where we want to be and how satisfied our customer should be. Main places where we define customer satisfaction are Service Level Management, Availability and Capacity Management.

Service Level Management
Now we are at the right place.

The goal of SLM is to ensure that the agreed level of IT service is provided. And that any services we will provide in the future will be delivered as agreed.

The alleged purpose of SLM is to provide the metrics for conformance of the achieved level of service to agreed one.

But in reality, the main goal of SLM is improvement of communication between Business and IT. The process of SLM is the most important and valuable process in creation of the service. It helps Business to KNOW what to EXPECT and also helps IT to know what is important to provide.

Service Level Agreement (SLA) is just a document. But the process of SLM helps IT and the Business to understand each other. Negotiations, request weighting, estimations, it all helps Business to understand what resources are involved and how difficult it is to achieve every little fraction of availability percentage. Also, SLM process helps IT to understand what and how is really important to business. So SLM is about bringing EXPECTATIONS in reality domain.

Service Availability and Capacity Management
Availability and Capacity are naturally opposed and they represent the process of narrowing the gap between what customer wants and what he is willing to pay for. IT is here to try to comprehend what is important to Business in order to stay alive in a cost-effective way.

So Availability and Capacity underpin the process of Service Level Management by educating the customer about the price of the service and finding the optimal investment/gain ratio. Customer will understand that price of availability grows exponentially. Simple math will find the adequate crossing of the cost and availability curves.

That's why ITIL says that "there is a direct correlation in most organizations between the service availability and customer and user satisfaction, where poor service performance is defined as being unavailable. "

Better communication and common language helps IT to stay alive even if some services deteriorate. It is still possible to retain most of customer's satisfaction if he knows he can have confidence in us.


SERVICE TRANSITION
Customer satisfaction is mentioned as a factor of high importance repeatedly in Service Transition Fundamentals and Principles.

During Transition, in Change Management and especially in Release and Deployment Management we get in touch with the customer and it is very important that these interactions create good experiences.

But, if we get to this ITIL implementation stage and something goes wrong, it will usually be much more visible in Operation phase, since badly implemented changes create a large percentage of RFCs and incidents.


SERVICE OPERATION
Most interaction with the customer happens in Operation stage, mainly in Service Desk function, through Request Fulfillment and Incident Management.

What we want to do is to optimize costs and quality in agreed service level:

Finding the Cost/Quality optimum for the Service

Customer satisfaction is the main KPIs for these ITIL entities. Most of the non-technical introduction to Service Desk chapter is actually about Customer Satisfaction. There is even a nice detail about customer/user satisfaction surveys (6.2.5.1).


CONTINUAL SERVICE IMPROVEMENT
A lot of attention is naturally given to customer satisfaction in Continual Service Improvement. Satisfaction is something you can measure, and what you can measure you can manage and improve.

Where I am from, gathering and reporting of customer satisfaction data is done in Service Desk, mostly after incident ticket closure and periodically on meetings with top ten customers. That conforms well to our ISO 9000 and ISO 20000 requirements. Every year on management review we check did we reach our last year’s goal, and define where we want to be next year. Let me remind you: it is not always about rising customer satisfaction: one year we even lowered target values of Incident Management survey results.

I have a few examples to illustrate the above for you:

Anecdote 1: In the early days of our service support we had a customer. We were over-capacitated and eager look our best, so we responded and resolved tickets for this customer much quicker than the Service Level Agreement required. Customer was happy. As we got more customers, our response times became longer and longer, but still well within SLA parameters. Our customer started to send unhappy signals in our regular satisfaction surveys, so we scheduled a meeting.

Problem wasn’t in our agreement, but in perceived deterioration of our service. Customer took our eagerness for granted. So we had a long talk, reset our SLA thresholds and financial parameters, and continued to cooperate. Nevertheless, we took care to respond to system incidents after 1/3 of agreed response time. For all customers. Just in case.

Anecdote 2: During the night, our system monitor tool notified our Service Desk on a major incident at our customer’s site. Our on-call engineers were called and started investigating immediately. They spent all night working on resolution and succeeded early in the morning.
Sadly, our Service Desk did not open an Incident in our ticketing application until the resolution. So customer was notified about the incident 5 hours after the service went down. And in SLA we have defined 2 hours response time, hourly notifications on priority 1 incidents, and resolution after 8 hours.
Our customer went wild (very dissatisfied). Even if we worked all night with doubled capacity to restore the service, we failed to meet the agreed notification time and kept the customer in the dark.

On the other side, if we only had created the incident record and notified the customer hourly that we work on it every hour, put one person on resolving it until the morning, our customer would be much happier.

Service Level Management is KING
Of course, there are all kinds of customers, some are nice people and some are less so, but at the end of the day, it all comes to delivering what you promised. So if your Operations processes are implemented well, usually a significant improvement can be gained by working on your Service Level Management process.

Opening Jagger quotes were just for my amusement. Here are a few Customer Satisfaction thoughts that I picked up for you:

- Your best customers leave quite an impression. Do the same, and they won't leave at all.
   SAP Ad


- Although your customers won’t love you if you give bad service, your competitors will.
   Kate Zabriskie


- Customers who don't get support become someone else's customers.
   Brigade Ad


- If the shopper feels like it was poor service, then it was poor service. We are in the customer perception business.
   Mark Perrault, Rally Stores


- You are serving a customer, not a life sentence. Learn how to enjoy your work.
   Laurie McIntosh


Related posts:

Customer Satisfaction Survey: What Methods To Use?
How to gather customer satisfaction data? What methods are there? What ITIL says? What methods will work for you?

Many Calls One Incident

Every time user calls in, we log it as the new incident. Or we update an existing incident.
What happens when one major business service goes down? Do we log every call from a different user as a new incident?
Are these just related incidents or there is only one incident? What are calls?

I have seen a few interesting discussions on the Net about the technology of Service Desk Incident logging.

Since I have some 18 years of IT Service Management experience in practice and in theory, and this is a matter I have a strong opinion about, I might say a few words about it.

INCIDENT MANAGEMENT PROCESS
Incident Management is the oldest and most chewed up process in all IT Service Management. Everyone does Incident Management. Maybe not Capacity Management or IT Financial Management, but Incident Management is in phase 1 of most ITSM/ITIL implementations. So it is the best defined and best known process. Everyone interested in ITSM knows everything about it. Right?

DEFINITIONS
What was the definition of an incident? Here are some:

• ITIL V2: any event which is not part of the standard operation of a service and which causes, or may cause, an interruption to, or a reduction in, the quality of that service.
   
• ITIL V3: An unplanned interruption to an IT service or reduction in the quality of an IT service. Failure of a configuration item that has not yet impacted service is also an incident, for example failure of one disk from a mirror set.
   
• MOF: Failure of a service or component to provide a feature it was designed to deliver.

Very nice. All bases covered. Very defined. For decades.

SCENARIOS
So consider a few scenarios:

• User cannot log in, she forgot her password. Service Desk creates a incident ticket and resolves it in a first call. Splendid.
   
• User has a problem with his PC. Service Desk assigns a technician on that incident . Technician visits the customer, resolves the incident and SD closes it.
   
• Print server goes down. No one in the headquarters can print. Imagine the legal department people. Sales girls and their Tenders & Invoices... Hell must be a nicer place to be. Phones are off the hook, percentage of unanswered calls goes up fast.

Imagine a mail server crash in a large enterprise. That must be a show. This is a very common case, happens every day in IT all over the world.

So then, is every new call from a panicking user a new incident? Or it is just one incident, and many end user calls (inquiries?). Read ITIL books V2 and V3 all you want and you won't find the answer.

V2 books are in favor of rule that every new call is an incident. OK maybe if the same contact person calls a second time, then it can (maybe) be logged in the same Incident record. But, another person, another Incident.

V3 broke Incident management into new Incident Management and Request Fulfillment with an eye on Event Management. So everything is not an incident any more, it can be an user request. Which doesn't help us here much. Every call about the incident is still an incident by our good ITIL books. And that's best practice. Sort of.

ITIL Service Management sure has some place for improvement here. What I feel sorry for is that authors of V3 strived to cover as much new territory they could (Knowledge Management? Strategy Generation?), creating more ambiguity and material which will need improvement, and flaws of the basic processes remain uncovered. Best practice system should cover such basic scenarios as above mentioned.

What happens in example above, if every call is an incident? All incidents are logged and categorized. A lot of them.

If a mail server went down, is it a new incident every time user notices he can't send mail? No, of course not. It's ONE incident, i.e. one interruption of the mail service. In a good Service Desk environment this incident will often be recorded before any user notices it. The amount of users impacted will only influence Priority of the incident, (remember, Impact X Urgency), not the number of incidents.

This is a nice question I have asked every ITIL trainer/consultant I've met, and I've always had fun.

HOW SHOULD IT BE DONE? 

So, how do you do it at home?

In my company, Service Desk has an Incident Management tool which enables us to log an Incident. All later calls from the same contact person (department) are logged as updates of that incident.

All later calls from new persons regarding that incident (mail server down!) are creating new tickets which are connected to that first incident. These related tickets are not considered incidents, we call them simply "tickets".

When the original incident is resolved, an original contact person for that incident is asked to confirm. Incident is then closed, and all associated tickets too. All contact persons from these tickets get a notification about the closure and are asked to reopen the incident if they feel their service is not yet restored.

Some tools on the market even have special entities, "Calls", which are linked to an initial Incident in a similar manner. Some other tools are at least able to interlink incidents so that when the original one is resolved, SD people can at resolve related incidents one by one, "on foot".

This scenario can repeat quite often in enterprise Incident Management, even in mid-sized managed service companies. So it would be nice if someone explained it to good ITIL best practices author.

NOTE

There is one potential catch with "One incident/Many tickets" method: if you treat various departments or business units of your company as different customers, i.e. you have a different SLA with Finance, Legal or Marketing, then you would want incidents and outages to show on their respective SLA reports. If your IM and reporting tools are not perfectly linked to the service Configuration Items in your CMDB or your Service Catalog item, you will probably want to create one incident for every contracted SLA.

This will also be the case if your contact defines a business unit associated with the incident, and the reporting tool regards incidents as service disruptions on associated business units. Here the value of a good Service Catalog/Portfolio comes to the fore.

Sometimes this vagueness is justified by “descriptive, non prescriptive” nature of ITIL. Well in my humble opinion, if something is called best practice, then it should describe the best practice of common events.

It would be very nice if this issue gets to be addressed in the next ITIL release, don't you agree?

Related posts:

Incident Management Elements
Key elements of Incident management.
http://itservicemngmt.blogspot.com/2007/05/i-will-go-through-main-elements-of-itsm.html

Incident Management Mind Map
Download the incident management mind map.
http://itservicemngmt.blogspot.com/2007/05/incident-management-mind-map.html

All About Incident Classification

How to deal with incident categories.

http://itservicemngmt.blogspot.com/2007/05/all-about-incident-classification.html

 

What Everyone Should Know About Incident Priority

Incident prioritization in ITIL.

http://itservicemngmt.blogspot.com/2007/06/incident-priority-what-everyone-should.html

  

ISO 20000 Rediscovered

"It is easier to do a job right than to explain why you didn't. "
- Martin Van Buren -

If we browse thru brief ITIL history, we can see that ITIL (or its basic concepts) was present in IT since the wheel invention. There lies the key to its popularity in IT service business. What can an IT business do to improve it's functioning, but turn to ITIL, or some of its derivatives, like MOF or ISO/IEC 20000? You educate and certify people, define your functions and processes and introduce tools for their automation. And then you are ITIL compliant. Or not?

ITIL is best practice guidance. In the V3 it becomes a bit more prescriptive, but still it stays a framework that basically tells us WHAT we SHOULD DO. In ITIL V3 there are some more ideas on HOW, but that's not its forte. You can define everything by ITIL recommendations, and it can help you a lot in your Service Management work, but you are still not ITIL compliant. Because there is no such thing as ITIL compliancy. You can measure your processes and report on them all you want, but no one guarantees that you made it there.

An international standard for IT Service Management, ISO/IEC 20000, is heavily based on ITIL. It deals with most important ITIL processes, but also adds some new. It defines requirements and code of practice for ITSM, and also provides the tools for assessment and audit of the system.

By ISO 20000, use of ITIL is not mandatory, but since 20000 is by its nature above ITIL in the pyramid, implementation and certification is much easier (read: “only possible”) if it is ITIL supported. ISO 20000 requirements are very short, not much juice there. HOWs and SHOULDs are in ITIL, SHALLs are in ISO 20000. So know your ITIL.

Also, it doesn't hurt if a company is ISO 90000 certified. You know, mindset and experience...

So, a possible path of implementing ITSM is combination of ITIL and ISO 20k: You define the phases of implementation with processes according the pain you feel in your processes. Also you implement ISO 20000 Plan-Do-Check-Act methodology and metrics for every considered process. Educate people, define the scope, processes and roles. Implement automation tools. Check. Act…

A tiny catch: ISO 20000 requires full frontal coverage, all processes have to be implemented. Scope can be limited only to a specific customer or part of organization. But you can keep your ITIL phased implementation, process by process, or in groups of processes. Apply what ITIL tells you, and implement what ISO20000 requires in each phase. In the end, you have a Service Management organization functioning on best practice principles and ready for ISO20000 certification.

ITSM pyramid

Certification
ITIL Qualification Scheme is for the people. Companies are not certified. Example: my company certified a bunch of people in ITIL Foundations 5 years ago. 95% of them left the company since then. In the meantime, we recognized the cost of repetitious certification of new employees. So we developed internal informal ITIL training, to support our business needs and processes. Only higher positioned people get formal ITIL certificates. We created internal support policies, procedures and work instructions, some of them included in our ISO9000 QMS, some external.

Now, ISO/IEC 20000 provides certification on a company level. External auditor (Registered Certification Body) conducts the review, and if the company meets the certification criteria, it can be certified and display the logo.

So if a company wants to be competitive, and introduce order and best practices in their service business, it should definitely think about ISO/IEC 20000 certification.

ISO20k doesn’t introduce much overhead, it just tells you in advance what things shall be done eventually, and keeps you from wandering in the dark. If implemented right, certificate should be a bonus, not the target.

Related posts: ITIL ISO/IEC 20000 Compared : ISO/IEC 20000 Essentials : Implementing ITIL and Staying Alive

ITIL - ISO/IEC 20000 Compared

General Comparisson
ITIL V2	ITIL V3	ISO 20000
Best Practice	Best Practice	Standard & Code of Practice
Individual Certification	Individual Certification	Certification of a Service Provider Organization and individuals (lately)
Best practice guidance, detailed description and implementation guidance	Best practice guidance, detailed description and implementation guidance slightly more prescriptive then V2	High-level requirements
Defines process and function roles and responsibilities	Defines process and function roles and responsibilities	Org. structure independant, defines few mandatory roles
Process based, 10 processes & 1 function	Service Lifecycle Based, 26 processes, 4 functions	Continual improvement based, 16 processes, no functions
Processes & Functions
ITIL V2	ITIL V3	ISO 20000
Planning to Implement Service Management	Continual Svc. Improvement	Planning and Implementing Service Management
Service Delivery	Svc. Strategy, Svc. Design, Continual Svc. Improvement	Service Delivery
Service Level Management	Service Level Management	Service Level Management
Service Reporting	- Reporting from SLM -	Service Reporting
Financial Management	Financial Management	Budgeting and Accounting for IT Services
IT Service Continuity Management	IT Service Continuity Management	Service Continuity and Availability Management
Availability Management	Availability Management
Capacity Management	Capacity Management	Capacity Management
- demand management from Capacity Management) -	Demand Management	-
Security Management	Information Security Management	Information Security Management
Service Support	Svc. Operation	Resolution Processes
Incident Management	Event Management, Request Fulfilment, Incident Management	Incident Management
Service Desk	Service Desk	- No functions in ISO 20k -
	Svc. Transition, Svc. Operation	Controll Processes
Configuration Management	Service Asset and Configuration Management	Configuration Management
Change Management	Change Management	Change Management
	Service Transition	Release Processes
Release Management	Release and Deployment Management	Release Management
	Svc. Design	Relationship Processes
-	Supplier Management	Supplier Management
	Svc. Strategy, Svc.Design, Svc. Improvement
	Parts of Service Portfolio Management, Service Level Management and Continual Service Improvement	Business Relationship Management

ITIL V3 Foundation Syllabus Change?

In a post ITIL Foundations Exam Go/No-Go from Oct. 27. 2008. I said something about the possible and needed changes in ITIL V3 Foundation syllabi.

For now, nothing has been announced officialy.
There is a new version of Interim ITIL V3 Foundation Certificate Syllabus, version 3.1 from 07. Feb. 2008.

In change comments it says that the reason for new version is updating the Copyright Statement with Crown Copyright. But also, several points of the syllabus are in red bold print, and I haven't seen the explanation for that.

Marked points are mostly from Service Strategy, and most people agree that it was over-emphasized in first V3 exams. ITIL Foundations exams in February indeed had fewer questions from Service Strategy then before.

So, risking to be completely off-target here, I presume that some change is gonna come and someone will inform us officially about it some day.

If someone spots an info on this somewhere, please point it out here. People all around are preparing for ITIL Foundations and it would be nice if they knew what to focus on.

Related posts: ITIL V3 Qualification Scheme : ITIL Foundations Exam - Go/No Go?

Links:

OK folks, here is an update: After a long review process, on 01.05.2009, there are new syllabi available for ITIL V3 exams:

ITIL V3 Foundation Syllabus
Link to the new V4.2 ITIL Foundation Syllabus

ITIL V3 Foundation Bridging Course Syllabus
Link to the new V4.1 Bridging V2/V3 ITIL Foundation Syllabus

ITIL V3 Managers Bridge Course Syllabus
Managers Bridge Syllabus V3.3

ISO/IEC 20000 Essentials

In a previous post I announced a few more words on ISO/IEC 20000. So here they are.

ISO/IEC 20000 is an international functionally based standard for IT Service Management. This functionally based means that it is not a broad general standard like ISO 90000. It was published by ISO (International Standards Organization) in mid December 2005., evolved from BS15000 with only a few minor changes.

HISTORY
During the ‘80s British Standard Institute’s Service Management Group worked on a code of service management practices, which covered 13 basic processes, aligned with the first version of ITIL. Final version of this code was promoted to a standard and published in 2000 as BS15000. It was the first world’s standard for Service Management. After initial testing on early adopters, additional polishing and changes for realignment with ITIL V2, it was republished in 2002. It was adopted by many service companies in UK, but also companies worldwide accepted it.

In 2005, BS-15000 was placed on the “fast track” by the ISO. By the end of the year it was published as ISO-20000 standard.

ISO/IEC 20000 and BS15000 are practically the same, only a few less significant changes were made in the process.


UNDER THE HOOD
ISO/IEC 20000 consists of two specifications: ISO/IEC 20000-1:2005 and ISO/IEC 20000-2:2005.

• ISO/IEC 20000-1:2005 is Specification and it defines Requirements for ITSM. Part 1 is very formal, it defines processes and provides assessment/ audit criteria.
  
• ISO/IEC 20000-2:2005 is a Code of Practice that gives HOW-TOs and describes best practices for implementation of Part 1.

The standard introduces elements of Quality Management (Plan-Do-Check-Act) in Service Management. Some parts of ISO17999 (ISO standard for internet security) are added. Also it is very much aligned with ITIL and speaks the same language. Basic ITIL processes are described and grouped in a following way:

1. Service Delivery:

• Service Level Management
• Availability Management
• Capacity Management
• Continuity Management
• Budgeting and Accounting for IT Services (Financial Management)
• Information Security Management
• Service Reporting

2. Relationship:

• Business Relationship Management
• Supplier Management

3. Resolution:

• Incident Management
• Problem Management

4. Control:

• Configuration Management
• Change Management

5. Release:

• Release Management

ISO/IEC 20000 Process Groups Model

WHO IS IT FOR?

All service oriented companies, and in particular for business organizations that provide IT services.

The way I see it, if you provide IT services, you need a fine balance of ITIL and ISO20000. ITIL gives you competence, and ISO20000 tells you how competent you are, protects company’s investment and knowledge, and gives you competitive advantage on the market.


CERTIFICATION
Certification Scheme for ISO/IEC 20000 is created and managed by itSMF. To formally confirm compliance with the norm, independent assessment can be performed by an itSMF Registered Certification Body.


ISO/IEC 20000 and ITIL
ISO20000 and ITIL are complementary, in a sense that:

• ITIL is a best practices framework which enables business organizations to establish a common language and understand + establish essential ITSM processes. ITIL says how things SHOULD BE.
  
  
• ISO20000 is a standard that enables business to implement and measure best practices. The main point is that the norm helps to objectively test if those practices have really been adopted. It says how things HAVE TO BE. And who is responsible if they aren’t.

Did ITIL V3 Ruin Everything?
In May 2007 ITIL V3 was published. Did this create a lack of balance between the two?
ISO20000 was aligned with ITIL V2. To be a true quality standard it had to adopt some ISO90000 and develop/evolve some processes. Primarily, it implemented Deming’s P-D-C-A lifecycle for continual improvement.




ITIL V3 caught up with ISO 20000, it is also lifecycle oriented, it adopted some of ISO20000 methods (PDCA) and processes (Security, Supplier Management and Service Reporting). In some aspects, we can say that ITIL and ISO20000 are more aligned now then before.

On the other hand, ITIL V3 significantly evolved in some higher level aspects. ISO will have to revise 20000 in the following years to anticipate this. But that doesn’t mean much to companies that are making first steps in standard adoption, since the early implementation path is focused on the basics, anyway.

ITIL gained a lot of popularity with IT professionals due to its earlier appearance, individual approach and market value for consulting/training companies. Last year's ITIL V3 hype also contributed to it.
Adoption of ISO20000 on the other hand, is a bit slower since it's primary value is to the company, and mixed individual interests of the stakeholders probably slow it down. Also it is more formal and strict, so that can scare away some businesses. With time, it will probably change, at least in companies that are really interested in return of their investment.

Related posts:
ITILV3: What's New?; ITIL V3 Qualification Scheme; Implementing ITIL and Staying Alive

And remember, last week I have put a few mindmaps for you to download:

• ISO/IEC20000 Specification Mind Map
  A set of requirements.
  
  
• ISO/IEC20000 Code of Practice Mind Map
  Guidance and recommendations on quality standards for ITSM.

Implementing ITIL and Staying Alive

At first sight, ITIL implementation path depends on who you are and what you do. And of course, with what do you do it. So: People, Processes, Technology.

At the beginning, let's move one starting dilemma out of the way: full frontal or phased approach? Phased, period. Strategically, you will have in mind full set of processes. But when you start, you want to dig deep and narrow, not broad and shallow. Hit the major pain points, ensure quick wins, and fly on the wings of starting success. This will enable you to move forward easier.

Critical factor number one? Management support. A lot of it.

From What Angle?

• You can try to imagine a well-organized company whose major pain is to know what it has, where it is and how it works. They have a stabile infrastructure with a low incident rate, and their Service Desk copes with it fine. But they implement a lot of changes and they want to gain more control over the Change and Configuration management. Of course, this is a fairy tale company, since a lot of hanges automatically means a lot of incidents, but just for the sake of the argument, this imaginary company would start it's ITIL journey in Change and Configuration Management.
  
• Or, maybe you are in a bank. Security is probably one of your biggest concerns. Maybe you want to start with Information Security and Access management. Depending on your country regulations, maybe you will even start ISO27000 certification. In some parts of the world it is a very likely case.
  
• Some service organizations with a high-end infrastructure (ASPs?) will be focused on geting their services definition right: Catalog, Portfolio, Demand, Suppliers, SLM...
  
• But, in nine out of every 9.1 cases, you are firefighting. In incidents up to your ears. Your left doesn't remember what your right has just done. Your customers are pissed. And because of the chaos you're in, you turned to ITIL. So you start from Incident Management. What a cliché.

So you decided to implement ITIL. How?

Simple: first you get a few ITIL Foundations certificates. Then you realize that you need a magic wand. What? Something to do the job for you. So, you realize that it is the tool that will take you on a journey. Of course, the TOOL.

You read some Gartner reports, evaluate some tools, and choose the best salesmen of evaluated tools. His implementing team is ITIL certified, his Tool is all Pink and shiny. Sadly, but this is usually the most critical point on your way.

You probably chose a good application, since most of the tools on the market are adequate for first steps in ITIL. At the end of the day, and at the beginning of your project, it all depends how good is your vendor. Because at most cases, he will be your ITIL consultant, too. So look closely. References, team certification, staff fluctuations.

To add some odds to your side, at least at the first phase of your project, hire an independent consultant. If you can afford one. This will probably save you a lot of effort, and eventually your job.

P.S.: If your company has ISO9000 certificate, it will be relatively painless for you to start preparing for ISO/IEC20000. You can implement the tool and ITIL processes, you can certify your people, but ISO 20000 offers you the mechanism for process definitions and audits. More on ISO/IEC20000 later, for now I've put a few mindmaps for you to download:

• ISO/IEC20000 Specification Mind Map
  A set of requirements.
  
  
• ISO/IEC20000 Code of Practice Mind Map
  Guidance and recommendations on quality standards for ITSM.