HP’s $10 billion SKMS

In August 2011 HP announced the acquisition of enterprise search firm, Autonomy, for $10 billion.

It is possible HP was just crazy and former CEO, Leo Apotheker, was desperate to juice up HP’s stock price. With Knowledge Management.

Within ITSM the potential value is huge. Value can be seen in tailored services and improved usage, faster resolution of Incidents, improved availability, faster on-boarding of new employees, and reduction of turnover. (Ironically, improved access to knowledge can reduce loss through employee attrition).

In 2011 Client X asked me for some background on Knowledge Management. I did prepare some background information on ITIL’s Knowledge Management that was never acted on. It seemed like too much work for too little benefit.

ITIL’s description does seem daunting. The process is riddled with abstractions like the Data —> Information —> Knowledge —> Wisdom lifecycle. It elaborates on diverse sources of data such as issue and customer history, reporting, structured and unstructured databases, and IT processes and procedures. ITIL overwhelms one with integration points between the Service Desk system, the Known Error Database, the Confirmation Management Database, and the Service Catalog. Finally, ITIL defines a whole new improvement (Analysis, Strategy, Architecture, Share/Use, and Evaluate), a continuous improvement method distinct from the CSI 7-Step Method.

Is ITIL’s method realistic? Not really. It is unnecessarily complex. It focuses too much on architecture and integrating diverse data sources. It doesn’t focus enough on use-cases and quantifying value.

What are typical adoption barriers? Here are some:

  1. Data is stored in a variety of structured, semi-structured, and unstructured formats. Unlocking this data requires disparate methods and tools.
  2.  Much of the data sits inside individual heads. Recording this requires time and effort.
  3. Publishing this data requires yet another tool or multiple tools.
  4. Rapid growth of data and complexity stays ahead of our ability to stay on top of it.
  5. Thinking about this requires way too much management bandwidth.

In retrospect, my approach with Client X was completely wrong. If I could, I would go back and change that conversation. What should I have done?

  1. Establish the potential benefits.
  2. Identify the most promising use cases.
  3. Quantify the value.
  4. Identify the low hanging fruit.
  5. Choose the most promising set of solutions to address the low hanging fruit and long-term growth potential.

What we need is a big, red button that says “Smartenize”. Maybe HP knew Autonomy was on to something. There is a lot of value in extracting knowledge from information, meaning from data. The rest of the world hasn’t caught up yet, but it will soon.

Updated: ITIL Foundation Certificates Since 1994

Using Exin data provided by Aale Roos (Twitter), I am able to estimate the number of ITIL Foundation certificates issued from 1994 to 2011. I now estimate 1,253,100 ITIL Foundation certificates have been issued since 1994, including ITIL v2, ITIL v3, and ITIL v3 Bridge, up 21% from 2010.

I estimate another 250,600 Foundation certificates will be issued in 2012.

Please click on the thumbnail for a larger version.

ITIL Exam 2011 Statistics


APM Group just released their final exam performance statistics for all of 2011. ITSMinfo blog is now presenting our unadulterated free analysis of SPAM marketing registration.

Note: Click on any image for a larger version. All numbers rounded to 100’s place unless otherwise obvious.

ITIL Foundation

The total number of ITIL V3 Foundation and V3 Foundation Bridge exams taken was 250,400 in 2011, a growth rate of 8% over 2010.

A total of 220,200 ITIL V3 Foundation and V3 Bridge Foundation certificates were issued in 2011, compared to 185,800 in 2010, a growth rate of 19%. The average pass rate was 88%, compared to 85% in 2010.

I estimate 827,100 ITIL V2, ITIL V3, and ITIL V3 Bridge Foundation certificates were issued since 2008.

ITIL Advanced Certifications

A total 27,500 Lifecycle exams were attempted in 2011, up 83% from 2010.A total of 21,300 Lifecycle certificates were issued in 2011, up 95% from 2010. The average passrate was 76% across all exams.

A total 17,000 Capability exams were attempted in 2011, up 55% from 2010. There were 13,700 Capability certificates issued in 2011, up 60% from 2010. The average passrate was 79% across all exams.

Managing Across the Lifecycle (MALC): 4,000 exams were attempted in 2011, up 128% from 2010. About 2,600 ITIL V3 Expert certificates were issued in 2011 based on the MALC exam, up 149% from 2010. The average passrate was 62%.

Of the ITIL V3 Expert certificates issued, 5,000 were achieved via the Managers Bridge, including 2,000 in June 2011, which was the last month the Managers Bridge was offered (thereafter only retakes were allowed).

The total number of ITIL V3 Experts minted was 7,600, up 88% from 2010. Approximately 16,200 Expert certificates have been issued since 2008.

Regional Variations



Cumulative ITIL Certs since 2008

These numbers are estimates based on number of exams taken multiplied by the pass rates. In some cases the pass rates are not available and I had to use a proxy pass rate. For ITIL V2 Foundation passrates I used the average V3 Foundation pass rate. For advanced ITIL V2 certifications I used 60% pass rates. These were as reasonable assumptions as I could make based on published data.

Click on the charts to see more detailed views.

My estimates for Foundation certificates awarded since 2008 are:

ITIL V2 Foundation: 142,000
ITIL V3 Foundation Bridge: 33,000
ITIL V3 Foundation: 548,000

My estimates for advanced ITIL certificates awarded since 2008 are:

V2 Practitioners: 9,000
V2 Service Managers: 18,000
V3 Experts (via Managers Bridge): 12,500
V3 Experts (via MALC): 2,500
V3 Experts (Total): 15,000


ITIL Certification Update for July 2011

The latest ITIL certification statistics are available here from APMG. As usual we have tried to make sense of the numbers. Click on the thumbnails to see more detailed views.

The graph above shows the number of ITIL Foundations exams taken since January 2009. Worldwide interest is continuing to grow a an annual 15% growth rate.

Worldwide interest is distributed roughly evenly between Europe, Asia, and North America. However, the North American share has declined from 29% in April 2010 to 20% in July 2011.

At the Intermediate exam level, the Lifecycle track continues to pull away from the Capability track. However, the Lifecycle track saw a large dip in July that wasn’t seasonal and wasn’t reflected in the Capability track. I suspect candidates were awaiting the arrival of the ITIL 2011 refresh before resuming Lifecycle track certifications.

By region, the Intermediate exams are dominated by Europe, which generates about half the total Intermediate certifications. North America, as a share of the total Intermediate certification market, has declined from 39% in January 2010 to 20% in July 2011.

The advanced certification include V2 Managers and V3 Intermediate, and V3 Managers Bridge exams. The V3 Managers bridge saw a huge spike in June 2011 just prior to the expiration of the exam. Afterwards it fell to a negligible level in July 2011. The number of newly minted ITIL V3 Experts dipped from 2,188 in June to 280 in July. It remains to be seen whether interest in the advanced V3/2011 certifications will grow now that the V3 Bridge track from V2 has been officially retired.

The graph below shows the growth in the total number of ITIL V3 Expert certifications since January 2009.


Is the ITIL V3 Expert Level Worth It?

Whether or not the ITIL V3 Expert is worth the money depends on the candidate’s background. Obtaining the ITIL V3 Expert level will NOT make anyone an expert at ITIL V3 or in IT Service Management. If you have a consulting practice related to the management of IT or IT Service Desks, the training and certification may give you some additional tools for you to apply to your consulting practice. The benefit, therefore, is how the consultant applies the material he or she learns, whether consulting or working within an organization.

The certification will not buy  much respect with potential clients or partners. There are many “paper” Experts who have little practical experience, and as many true experts who are not certified. The world knows the certification is not very meaningful. In this way the ITIL Expert level is similar to other industry certification, including those from Microsoft and Comp TIA.

Why isn’t the ITIL Expert similar to programs from PMI or ISACA? Because those programs require documented experience in the area of certification. In this way the programs testify to the knowledge AND experience of the credential holder. ITSMF is compensating with the priSM program. PriSM is new and has yet to demonstrate how much value and staying power it has, but it is a step in the right direction. What’s wrong with priSM? The applicant is required to be a member of ITSMF, something not required for credential applicants and holders of PMI’s credentials (PMI gives discounts to members instead).

I am studying for the ITIL Expert. If I don’t believe it in, then why am I doing it? It is hasty to say I don’t believe in it, but I am enrolled because it forces me to study areas of ITIL where I am weak. I do have several years implementation and consulting experience with service desks. However, I am weak on strategy, a domain more typical of the CIO role. I look to the certification to help me round out my knowledge and make me more confident to speak in other areas. By the way, will I become a “Professional” of the priSM program? Maybe, if I can ever be bothered to join (hint, yes, but not yet).

Are Standard Changes “Good”

ITIL practitioners commonly assume that standard changes are good, and that a high percentage of standard changes vs. normal changes indicates a mature environment. Is this maturity “good” by definition with respect to Change Management? The answer is mostly yes, but not always.

Let’s look at some ITIL definitions. ITIL defines a change as:

The addition, modification, or removal of authorized, planned, or supported service or service component, and its associated documentation.

This definition in ITIL necessarily broad and not very actionable. Every company must define on their own what is and what is not a change. For example, one customer of mine defined their Change Management scope around the financial system necessary to achieve SOX compliance. They defined specific servers, workstations, and application by name in their Change Management policy. Although their definition was narrower than most companies’, it nevertheless worked for them.

The execution of an individual Change typically contains the following steps (in various orders):

  • Recording the Change, along with some basic information about it.
  • Reviewing the Change, including filtering out Changes that are useless, ill-conceived, or otherwise inappropriate.
  • Assess the Change, including analysis of risk, efforts, resources, and possibly more detailed feasibility analysis.
  • Authorize the Change
  • Implement the Change
  • Review the Change after implementation

The most important differences between normal and standard changes are in the assessment and implementation. ITIL defines a standard change as:

A change to service or infrastructure for which the approach is pre-authorized by Change Management that has an accepted and established procedure to provide a specific change requirement.

This definition is strong but incomplete. Standard changes are typically low risk, low impact, highly repeatable, well-documented, and well-understood. Standard changes are pre-authorized by the change board or relevant authorization parties.

Typically when an organization initiates a formal Change Management process, they will have few or no standard or pre-authorized changes. As they learn and grow, they will s identify some changes that occur frequently and are low risk and low impact, and further authorization of each individual change will burden the change board.

Such changes are candidates to become standard changes. Somebody, typically the person who implements these changes, can raise a change for the purpose of pre-authorizing a specific type of change. If authorized through the Change Management process, a new standard change is born. As a consultant I recommended these standard changes should become quick change templates in the ticketing system.

In general the longer an organization has been doing Change Management, the more standard changes it will have defined, and a higher percentage of all changes will be standard changes. This is a good thing, and in general the process of defining the the implementation plan (or change model) for standard changes helps to build repeatability and organizational learning and maturity.

Is a high percentage of standard changes ever a bad thing? In general no, unless the organization is so focused on measuring percentage of standard changes that technicians stop recording normal changes. This is bad, but rare in practice (at least for this purpose).

Standard changes can be difficult to achieve in organizations that are very dynamic or growing rapidly. In these environments it can be difficult to identify classes of normal changes that are candidates for pre-authorization. Growth consumes cash, and growth consumes resources. Highly dynamic environments may simply not have the people and time required to define standard changes, despite the benefits in more static organizations. Standard changes indicate operational efficiency, and not all organizations define their strategic competitive advantage around operational efficiency.

Changing Priority

Question: An Incident meets the criteria for P1. However, midway through resolution the impact has changed to that of P2. How should we treat the Incident now? How should we measure the SLA, based on P1 or P2?

Answer: I don’t believe ITIL provides much specific advice about this condition. How you want to handle this is really up to your organization and, more specifically, your Incident Policy.

In general organizations will prioritize Incidents based on the Impact (i.e. how many people or systems are affected) and Urgency (how long the organization can function with that service down or degraded).

Was the original assessment of Impact and Urgency incorrect? In this case you should change the prioritization.

Did the impact change because you applied a fix or workaround? In this case you should not change the prioritization.

Your SLA’s usually measures to full restoration. You could also measure to workaround provided. Your SLA’s won’t usually include fractional measurements based on changes to prioritization. For that matter, most organizations don’t even have formally agreed SLA’s with their customers.

Challenges Generated by the Implementation of the IT Standards COBIT 4.1, ITIL V3 and ISO/IEC 27002 in Enterprises

Abstract: The main purpose of this paper is to emphasize the importance of the implementation of IT best practices in enterprises and to identify the key challenges managers are facing when creating a standardized IT control framework in order to achieve alignment of best practices to business requirements. First, the authors present the increasing necessity of implementing IT standards in organizations acting in IT environments with focus on the standards COBIT, ITIL and ISO/IEC 27002. Second, the paper develops the analysis of the three standards which is a guidance for organizations wishing to adopt IT best practices on how to integrate the leading global frameworks and other practices and standards in inter-organizational relationships. The last part concentrates on the best methods of implementing in an efficient way the IT standards, which include identifying the use of standards and IT best practices, prioritizing processes according to an action plan and planning the steps of the implementation approach.

Reference: Năstase, P., Năstase, F., & Ionescu, C. (2009). CHALLENGES GENERATED BY THE IMPLEMENTATION OF THE IT STANDARDS COBIT 4.1, ITIL V3 AND ISO/IEC 27002 IN ENTERPRISES. Economic Computation & Economic Cybernetics Studies & Research, (3), 1-16.

Link: http://www.ecocyb.ase.ro/articles%203.2009/Pavel%20Nastase.pdf

From the paper:

COBIT provides best practices and tools for monitoring and mapping IT processes while ITIL aims to map IT service level management and ISO 27002 provides guidelines for implementing a standardized information security framework.

There is nothing in this paper that is original, and even less that is intelligible. Moving on.

What is the dividing line between a Project and a Change?

When is a Change really a Project? ITIL simply says the following are not changes:

  • Changes with significantly wider impacts than service changes, e.g. departmental organization, policies and business operations – these changes would produce RFCs to generate consequential service changes
  • Changes at an operational level such as repair to printers or other routine service components.

It isn’t clear to me that the natural agency—PMI—offers any clear guidance. PMBOK defines a project as a temporary endeavor undertaken to create a unique product, service, or result. Temporary endeavor implies a definite beginning and end.  Unfortunately, this definition is not inconsistent with a Change.

PMBOK offers little guidance about how big or how little a project needs to be in order to become a “Project” except to say the PMO exists to support project managers including developing a methodology, best practices, and standards. I would say a project is a “Project” when the benefits of managing it as a “Project” outweigh the overheads of the PM method. Hence the answer is organizationally dependent. If the organization’s PM methods are non-existent, then you can call anything a “Project” and send it off the secretary masquerading as a PM.

If the PMO’s PM method is detailed and rigorous, then projects would be greater than 80 hours at a minimum. However, in order to avoid the tendency of middle managers to “break up” projects in order to avoid PMO oversight, PMO’s will generally make the PM method scalable, requiring less overhead and oversight for smaller projects and more for larger projects.

In general time alone is a poor indicator for defining the boundaries of a project. A PMO should also look at factors such as strategic alignment, whether the Change supports or endangers the company’s strategy, and the project’s risk profile. Riskier projects should be overseen by the PMO in order to ensure the risk profile is in line with its support of the strategy.

In most organizations the PMO is more strategic and is independent of the IT operational processes. The Change Manager may hear about projects a few days before they are expected to go live (as a Change). In other words, the Project usually precedes the Change, not the other way.