All I Really Needed to Know About Titanic’s Deck Chairs I Learned From ITIL

Headline have a tendency towards hyperbole to grab attention, and there is no shortage describing the dwindling role of the CIO. Here is a recent one: IT department ‘re-arranging deckchairs on the Titanic’ as execs bypass the CIO.

As reporting of technological change increases,the probability of comparing IT tor e-arranging deck chairs on the Titanic approaches 100%. 1 – Tucker’s Law 2

It is true, CIO’s are challenged by technological change. The widespread adoption of cloud-based services by business units bypassing the traditional IT function is well documented. Support and adoption of consumer devices, including mobile phones, tablets, and non-standard operating systems such as Mac OS and Android, is also challenging traditional IT functional units.

Specific to the cloud example, some further examination is helpful. We don’t need to reinvent a framework, because ITIL 2011 already provides one. Service Strategy section 3.3 (p.80) describes three types of service providers:

  • Type I — Internal service provider. Embedded in an individual business unit. Have in-depth knowledge of business function. Higher cost due to duplication.
  • Type II — Shared services unit. Sharing of resources across business units. More efficient utilization.
  • Type III — External service provider. Outsourced provider of services.

Furthermore, ITIL describes the movement from one type of service provider as follows.

Current challenges to the CIO role come in 2 directions:

  1. Change from Type II to Type I, or dis-aggregation of services to the business units.
  2. Change from Type II to Type III, or outsourcing of services (presumably) to cloud providers.

In fact the CIO may be seeing both at the same time, as traditional in-house applications are replaced with cloud services and the management of those services and the information supply chain are brought back to the business unit. The combination of those two trends together could be called a value net reconfiguration, or simply, re-arranging the deck chairs on the Titanic.

Is this a necessary and permanent shift? Maybe but probably not. I personally believe that part of the impetus is simply to bypass organizational governance standards such as enterprise architecture and security policies. Business Units can get away with this for a while, but as these services realize failures and downside risks, aggregated IT functions will have take back control.

This does not mean the end of cloud adoption. Far from it. It means that the CIO will orchestrate the cloud providers, in order to optimize performance and manage risk. The CIO is as necessary as ever albeit with a different set of requirements.

Peter Kretzman has successfully argued that the reported demise of the CIO has it backwards: IT consumerization, the cloud, and the alleged death of the CIO.

Kretzman has also argued the dangers of uncoordinated fragmentation: IT entropy in reverse: ITSM and integrated software.


1 In 1990 Wired Magazine published the observation that as an online discussion grows longer, the probability of a comparison involving Nazis or Hitler approaches 1.0. As an experiment in memetics, it taught us a lot about psychological tendencies towards hyperbole. The Wired observation is now termed Godwin’s Law of Nazi Analogies.
2 Consulting firm Forrester has provided us enough ammunition for Tucker’s Law as a corollary.

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



One Step Backward, Two Steps Forward

I am proud to announce that I have started a new position in November 2011. It is a one-year contract in Tokyo to help transform the local, shared IT service provider to a global infrastructure utility provider. My position involves the discovery and implementation of processes based on good practices from ITIL. The project involves a number of challenges that are typical of global organizations, ranging from technical to political, and involving people, process and technology. I am excited to take on these opportunities.

My blogging and social networking have been reduced as a result of the schedule change and demand loads, but I appreciate everyone’s support and I am adapting my production around my new schedule. Please stay tuned for lots of good things to come.

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.


The Problem of CSFs

If you are unable or unwilling to appoint a Problem Manager, you are not ready for Problem Management.

That’s what I said. Or at least I think that’s what I said.

The venerable and ubiquitous Chris Dancy quoted me this January 2011 on episode 1 of the re-formed Pink Elephant Practitioner Radio podcast. He quoted me as saying “you can’t do Problem Management without a Problem Manager”. I finally listened to it last Friday.

I want to apologize to Chris. First, I apologize that I didn’t listen to his podcast earlier. I am a couple months behind on my podcast queue. Second, I apologize that I didn’t thank him personally at #PINK11 in February for the mention. I love Chris in almost every conceivable way.

I don’t fully agree with the paraphrase. I think a company can successfully implement a Problem Management process without a Problem Manager. What I really wanted to say was this: If you are unable or unwilling to appoint a Problem Manager, you probably haven’t achieved all the critical success factors you need to successfully carry out Problem Management. Unfortunately, this sentence doesn’t tweet well, so I abbreviated.

ITIL v3 Service Operations lists the critical success factors for Service Operations processes:

  1. Management Support
  2. Business Support
  3. Champions
  4. Staffing and retention
  5. Service Management training
  6. Suitable tools
  7. Validity of testing
  8. Measurement and reporting

All of these are necessary to successfully implement Problem Management. Organizations that lack any of these factors won’t appoint a Problem Manager. My advice to organizations, then, is very simple: appoint a Problem Manager. If they cannot do this, they are not ready for Problem Management.

In fairness, a few organizations do meet all the above CSF’s and choose to implement Problem Management without a centralized point of contact. It is the responsibility of managers to perform Problem Management activities inside their own group. Organizations with the right culture can get away with this. Most organizations cannot.

For that matter, most organizations cannot muster the courage or resources to appoint a Problem Manager.

Rethinking the CMS

I first started this post in response to the IT Skeptic’s CMDB is crazy talk post about 2 weeks ago. My own position derives from several observations in the real world:

  1. Few organizations are willing to perform a full spectrum CMDB implementation, due to cost constraints. (In my opinion few organizations actually require this.)
  2. Observation #1 even includes those organizations that have purchased a commercial CMDB software package. They purchased the software to achieve a more specific objective.
  3. And yet most organizations perform some level of configuration management, even if that is as simple as tracking software licenses on a spreadsheet.
  4. Most organizations would benefit from doing a little more than they are currently doing. The “what” depends on the organization.

The ITSM community needs to stop thinking about the CMS / CMDB as a process (which has defined inputs and outputs) or a thing or a database. Instead we can think about it as a broad collection of activities that help maintain information and documentation on the configuration of assets and software inside an organization. This isn’t a black or white implementation where you do it all or you don’t do any–most organizations span the spectrum of gray.

The trouble with ITIL (as if there were only one) is the concept of a CMS is so abstract that most people cannot understand  it. This is by design–it saves the authors the trouble of actually doing anything. I still have trouble describing ITIL’s take on the CMS, and I have done practical implementations in a dozen organizations.

Let’s help practitioners by enumerating and describing the various CM activities that take may take place that are common in the real world. We will explain the benefits and costs associated with each.

For example:

  • Automated discovery of hardware assets
  • Automated discovery of installed software assets
  • Automated discovery of network assets
  • Automated linking of software and hardware assets
  • Automated linking of hardware and network assets
  • Automatic reporting on software compliance and unused licenses
  • Linking Incidents to CI’s
  • Linking Changes to CI’s
  • Linking Problems to CI’s
  • Linking CI’s to end-users
  • Linking CI’s to end-user organizations

This list is VERY incomplete, and there is no out of the box solution for any of the above. There is a wide variety of expression of CI names, CI types, attributes, and statuses of the above items. Each can be automated to different levels.

By making a checklist we can help practitioners and organizations understand what they can do, what other organizations do, and what they should consider in the future. It would be a list of available options, rather than a document of the One True Way dictated high from above. We can expand on Skep’s checklist concept.

A checklist of practical activities could also feed into a maturity assessment.

We can call it the Management of the Configuration of the Configuration Management Database Database. Or we can call it WikiCMDB for short. Stay tuned here for more details.

I am thinking out loud, so everything in this post may be wrong. I welcome your feedback.

The Problem of Revealed Preferences

Consumers express their rational interests through their behaviors. Economists call these revealed preferences.

IT Service Management trainers and consultants tell other companies how they should run their businesses, based on industry best practice frameworks. We seldom examine revealed preferences, but perhaps we should.

One of my first engagements as an ITSM consultant involved the planning and implementation of a Problem Management process at an organization that had committed to widespread ITIL adoption. For several years after I was an acolyte of Problem Management.

I have implemented Problem Management at a dozen customers and tried to sell it to even more. Among the latter, most resisted. The excuses often included “we are too busy putting out fires”, “we aren’t ready for that”, and “that’s not our culture”. Perhaps I wasn’t selling it well enough.

Most organizations do ad-hoc Problem Management, but few organizations have defined processes. Their reasons probably contain some legitimacy.

Organizations do need to be in control of their Incident Management process before they are ready for Problem Management. They do need to be in control of putting out fires and fulfilling service requests. Most organizations find themselves with a backlog, even those under control, and that is alright. A reporting history is a prerequisite.

Organizations must also be in control of its Changes. The resolution of known errors take place through Change Management, and organizations in control of Changes are better able to prioritize the resolution of its known errors. Anyway, at most organizations, an effective Change Management process is more beneficial than Problem Management.

I usually told customers they were ready for Problem Management only if they could devote at minimum one-quarter to one-half of an FTE to the Problem Manager role, and this person would need to have a good overview of the architecture or be well-connected throughout the organization.

In other words, the Problem Manager should be reasonably senior and independent of the Service Desk Manager. Without this the Problems will be starved of resources. Someone needs to liaise with senior management, ascertain business pain points, prioritize tasks, acquire resources, and hold people accountable. In other words, Problem Management requires commitment at senior levels, and it isn’t clear all organizations have this. Many don’t.

There is another reason that is more important. Organizations that are so focused on executing strategic projects won’t have the resources to execute Problem Management processes consistently. There are several reasons this can occur. In one instance the organization had acquired another and had dozens of projects to deliver on a tight deadline. In another, the reverse situation was occurring, as they built functions to replace those provided by a former parent company. In another, the organizations simply put a lot of focus on executing projects in support of the organization’s new strategy.

Some organizations plainly require Problem Management processes. I have seen more rigorous adherence among organizations who provide IT services to other technical organizations, such as data center outsourcers, hosting providers, or organizations who provide services such as video distribution or mapping to telcos. When services are interrupted, the customers demand root causes analyses.

But it is probably true that many organizations don’t need or aren’t ready for Problem Management. Problem Management is an investment, and like all investments should deliver returns that exceed not only its own costs, but also exceed the benefits of similar efforts the organization may undertake. So it has been revealed.