Becoming an ITIL Expert

The ITIL® Expert qualification, the penultimate award in the ITIL stack, is not easy, but it is achievable, and if you put in the study time, and pay attention, then it is fairly straightforward.

Contrary to popular belief, there aren’t any nasty trick questions. There are tough questions in the intermediate exams and higher, but tough in a way that gives you an unclear choice between picking the answer that is ‘most ITIL’ or ‘best answers the question/case study’.

Your first choice, after deciding to pursue the Expert qualification (either from start to finish or over a number of years as I did) is which route to take.

Expert Paths


There are 3 main routes to your Expert qualification:

1. Conversion from V2 Manager

As a single course/qualification, this was retired in 2011. However for those who missed the boat and hold the V2 manager’s cert, there is an expedited route to ITIL Expert:

  1. ITIL Foundation / Foundation Bridge, then
  2. ITIL Intermediate Lifecycle : Service Strategy OR Continual Service Improvement, then
  3. ITIL Managing Across Lifecycle (MALC)

2. The direct Lifecycle or Capability paths

This involves taking the following exams:

  1. ITIL Foundation
  2. All ITIL Intermediate Lifecycle or all Capability certificates
  3. Managing Across the Lifecycle

You’ll notice that you get a choice in step 2. The Lifecycle qualifications are aimed more at the consultant or manager, whereas the Capability qualifications are aimed more at the practitioner.

There are other differences as well. If you choose to study for these in the classroom, then the Lifecycle courses are all 3 days each so you’ll spend 15 days out of the office. The Capability courses are 5 days each so you’ll spend 20 days. This can be an added cost for contractors & consultants (on daily rates) or those who have limited training days available.

Cost of the courses is another consideration. A quick check of the list prices for each course on a popular UK training provider’s website shows Lifecycle courses costing £1245 and Capability courses costing £2300. This means that the Lifecycle route will cost you £6225, and Capability £9200. And you still need to pay for the foundation and MALC whichever route you choose. Even if you go down the Lifecycle route, you’re not getting much change from £10k – though this gets a lot cheaper when done via online learning (more on this later).

Note that if you’re paying for this yourself as an individual rather than a company, tell the salesperson when you call for a quote – they usually do discounts of 20 – 30% for individuals, and multi-course discounts are also available. Discounts tend to be greater in Q2 and Q3 of each year when training budgets have been spent (or held on to). Also make sure you ask about free re-sits in case you don’t do well on your first attempt.

3. Indirect path (mixture of Capability, Lifecycle & others)

The final route to Expert is a hybrid approach. You can combine Lifecycle and Capability qualifications as well as some of the shorter specialist courses to get the credits you need – but be careful. Where there is overlap in the various syllabuses, the examiner does discount the point scores for individual certificates as explained in the following links:

The routes to ITIL Expert are summarised in the diagram near the top of this page, and there’s also a very good diagram by Peter Lijnse at ServiceManagementArt available here which also shows how the topics are carved up differently between the 5 Lifecycle and 4 Capability courses.

What about online?

It’s possible to go from novice to Expert via online-only study. But should you? There are major cost benefits (up to 65% off the price of classroom) to studying online and online delivery & examination methods are maturing rapidly, though make sure you stick to reputable and accredited training organisations. Some recommendations are included later.


Studying ITIL Foundation online is both cost & time effective and can be a very viable option for many people. It’s also the easiest of the ITIL qualifications, though what it lacks in depth, it more than makes up for in breadth. You’ll cover a lot of concepts in a short space of time, and the main value I found in the classroom was in having the instructor give a joined up overview of the whole end to end lifecycle.

You can order ITIL online training from many providers, or buy single books / complete certification kits from online retailers.

Booking & taking the foundation exam is also pretty straightforward – one of the main popular providers is Prometric/EXIN.

Google will show many online training providers, but if you want a recommendation then check out ITIL Training Zone for Online ITIL Foundation Courses.

Intermediates & MALC

Taking the intermediate exams online is a little bit more involved. Whereas for the foundation you could just read a book and rock up to a test centre, for intermediates you need to have studied via an accredited training provider (ATO) and for a minimum length of time.

There are some ATOs who are accredited to deliver online training however, such as ITIL Training Zone who deliver the full range of online ITIL courses.

Taking exams online from your own home or office is also possible. You can usually sit a webcam-proctored exam, and some exam boards even offer the chance to have an independant third party monitor you whilst you sit an online exam (with dedicated software which locks the mouse/keyboard to the exam app and fails you if you exit the application). It is also possible to go and sit (once you’ve paid) one of the classroom exams run by other training companies as long as you have you attendance certificate from the online ATO (though this policy may vary from company to company – check first).

Having taken Service Operations via the online route, I’d recommend it for anyone who finds self-paced learning preferable, or who doesn’t want to take the time off work, or who already understands the material well and just needs it formalising before taking the exam. It’s also a lot cheaper. Most of the core learning courses are around $500, rising to $800 or so for the full package including exam prep questions and the exam voucher.

Seriously consider getting the exam prep kits. They’ll clue you into the question formats and get you used to thinking the right way. Where the foundation was a fairly easy multiple choice with one right / three wrong answers, the Intermediate exam questions have 4 right answers, but some are more right than others.


10 ITIL Intermediate and MALC exam tips

1. Study. Not just the specific course, but scan back over the foundation material as well.

2. Take practice exams and read the answer rationales. You may not agree with the rationales, I didn’t for half of them, but they give useful guidance on what the examiners are looking for.

3. Ignore Bloom’s Taxonomy easy/medium/hard ratings. The difficulty varies from person to person. It may match your ability perfectly, it might not.

4. Don’t change your answer unless you made a blindingly obvious mistake, but even then be careful. Unless you have a good 10 minutes left on the clock to really get back into a question in detail, leave it.

5. The best answer is usually the one that gets 3 things right: it’s the most ‘ITIL’, it best matches the case study, it best answers the specific question.

6. Because ITIL focuses on value, answers which talk about ‘value’ or ‘business value’ can be words to look out for in correct answers – but don’t rely on this, especially if you can’t make the rest of the answer work.

7. If going down the Lifecycle route, take Service Strategy & CSI last before your MALC. Strategy & CSI have the most overlap with the MALC syllabus and will be fresh in your mind.

8. For Lifecycle exams, avoid the answer which rushes in and starts doing things. The best answer is usually one that takes a step back and considers the whole situation and thinks more strategically (exception if the word ‘tactical is used’).

9. Avoid answers which involve some kind of ‘wacky scheme’ (like starting your own IT Hardware business when the question was asking about problem management).

10. Don’t mistake ITIL world for your world or experiences. Just because you’d do it one way doesn’t mean ITIL will.


Good luck – let me know in the comments how you got on!

DevOps and ITIL: Continuous Delivery doesn’t stop at software

DevOps. The next saviour of the world. A combination of agile delivery and super-effective provisioning scripts with a sprinkling of software-defined (virtual) infrastructure.

Whilst ITIL v3 and 2011 seem (on the surface at least) to support a waterfall approach, it’s imperative to step back and think for a second.

The concept of identifying a need for change to your service portfolio hasn’t altered. It still relies on identifying demand and building a decent relationship with your customers.

You still need to design it, and you’ll still need to operate it and continually improve it.

The biggest difference here is your transition strategy, transition design and the execution of transition. If you have waterfall style release policies and service validation practices then these won’t be capable of dealing with DevOps style Continuous Deliveries out the box. Sure, you can slice and dice your delivery packages down into smaller and smaller pieces, but this is still going to be at odds with the kinds of flexibility DevOps promises.

So let’s step back to Service Strategy and Service Design. In a traditional waterfall approach, an example of a high level transition plan is:


Delivery Contents
Delivery 1 (June)
  • Functional requirements a, b & c.
  • Pair of DB servers, single application server, single web server, no loadbalancer.
  • Non-functional requirements x,y,z meeting 75% of targets.
  • Documents 1,2 & 3.
  • Ops briefing at t-3 weeks.
  • ELS to +5 days
Delivery 2 (Nov)
  • additional functional requirements d, e & f.
  • Additional webserver with loadbalancer.
  • Non-functional requirements x,y,z meeting 90% of targets.
  • Documents 4,5 & 6.
  • Full training plan from t- 5 weeks
  • ELS to +15 days


These are packages. Discrete units. Similar to this site’s logo (which may need to change now!). You have built entire releases comprising some software components, some hardware, some documents, some knowledge transfer into a bundle. And this works really well for big deliveries, and even slicing these up into smaller 2-3 week deliveries is possible albeit with some overhead.

But what about daily? What about the developers with testers sat next to them checking in quality tested code on a daily basis to an automated build server, having it integrated, auto test packs run and then pushed to production? How are you going to slice release packages across multiple developers cutting code for variable prioritised lists of business requirements?

Packages now become unwieldy. You need a different transition strategy, and a different transition design, and you need to execute them differently from the packaging or bundling concept.

How? Rather than a conveyor belt of packaged releases, this becomes concurrent streams of smaller deliverables, for example:


Stream Frequency Roles /
1 – Code objects checked in, tested & deployed Daily R&DM, SACM
2 – Knowledge updates created & tested for the new functional requirements Every other day SACM, SV&T, Knowledge Management
3 – Formal Operational acceptance tests 1-2 times/week SV&T, SLM, BRM, App/Tech Function Managers
4 – Hardware deliveries As required R&DM, Tech Mgmt
5 – ELS & Continual Service Improvement Daily CSI, SLM, BRM, Service Owner


You’ll notice that I’ve referenced existing ITIL processes, functions and roles. We’re still using best practices (or good practices if you prefer) which are tailored to your organization and may need to be tailored for this approach. But the concept of creating a new knowledge CI and linking it to a functional requirement doc, service & hardware CIs and accounting for its status and verifying it is not new.

You need good tooling, you need reasonably mature Config Management and ditto for knowledge management, but there’s no reason why if it isn’t already happening in your organisation that you can’t use your DevOps approach to implement good config & knowledge management at the same time.

Change Management is still change management. Very little needs to (pardon the pun) change. It still acts as an approval/authorisation broker at various stages over the lifecycle, it can still devolve production release approval to the automated build and integration test process. But this is a policy addition driven by your transition (and service) strategy, not a whole new process.

You’ll also notice I’ve lumped ELS (Early Life Support) and CSI together. ELS never ends under this approach. But think back to the joining of Dev and Ops and you’ll realise that ELS loses significance. I’ve kept it here because there are some really good ELS practices you’ll want to keep: good defect/incident management at a heightened level with a razor-sharp focus on issues caused by change, regular sunrise/sunset meetings with sponsors and business owners. But I’ve merged it with CSI because this complements the very nature of Agile and also crucially gives you a perfect opportunity for a closed-loop feedback system into either operational, tactical or strategic improvements on a daily basis.

So you don’t need a dedicated DevOps process. You need a DevOps -focused transition strategy, design and execution. You need sensible tweaks to existing processes and policies. You need good tools for build, test, config and knowledge. You need good practices and good leadership.

You can do all of this with existing ITIL, just as you can with any other framework.

What happens when you ignore service design and acceptance.

I recently discussed service support / operations on twitter with someone frustrated at being asked to provide support for a public cloud service he had very little ability to. Not technical capability, because he seemed capable enough, but access to the systems to do more fundamental fixes. We didn’t get far into the details, but it seemed he was being asked to deal with something which hadn’t been thought about when the service was provisioned.

This is sadly not an uncommon situation among support teams who often have no say in the choice of system/service, no time to get familiar with it, and no means of pushing back on critical gaps even if they do get a chance to see it beforehand. These are often gaps that a 5 year old could often spot, let alone experienced engineers but which seem to be frequently ignored by people whose shopping list only has one thing on it: functionality.

Continue reading

Change requests: get the basics right

Most change requests get raised, authorised and implemented.

When I’ve had occasion to post-mortem a failed change for a new client, I’d usually expect to hear one of the following phrases:

  • I didn’t know what I was supposed to be doing
  • It shouldn’t have broken that, it was supposed to be totally unrelated…
  • How was I to know the backups were running at the same time?
  • Wait….I thought John was doing that reboot?
  • We only overran because we had to back it out…

…all of which are avoidable.

Continue reading

Here’s how you define change.

I just read an article on an ITSM blog I stumbled across where the author briefly discusses the confusion that can arise when people talk about different types of change.

The author raises a valid point about operational change versus standard change etc. and this is a problem I’ve run into in the past.

So let me give you the way I solve it.

There are two things we need to define here:

  • Attribute = how you describe a change in terms of priority, impact, type, category etc
  • Process / Route To Production (R2P) = how you deal with a change which can be described by a combination of one or more attributes – eg. Normal change, operational change, standard change, emergency change, service request….

Continue reading

The single biggest killer of releases

There are many reasons why releases fail. Maybe your test pack wasn’t scoped properly or that harmless application patch from the vendor removed a key piece of functionality. All of these pale in terms of avoidability and regularity in comparison to the following conversation:

Requestor: “I want this change to go into the release.”

Release Manager: “Sorry, the scope has closed, we’re scoping the next one though.”

Requestor: “But that’s too long to wait, it has to go in NOW.”

Sound familiar?

Continue reading

Release Management amplifies the effects of your change process (good or bad)

Let’s generalise for a moment. Release management usually comes into effect in two significant circumstances:

1. When you want to bundle changes into a package

2. When you want to fully ‘transition’ a service into operation and deliver the associated support and knowledge etc

In both of these circumstances, the output of the release will be an amplification of the inputs, ie. the component changes.

Continue reading

Building the Release process in 3 steps

1. High Level

Aligned to your release model, details the major stages of a release: plan, build, accept and deploy and how the lower level activities fit within that: scope, requirements, build & test, acceptance, implementation, early life support and also show checkpoints (scope finalisation, build completion) and show gateways which align to your other processes such as governance, Change Advisory Boards etc). It’s also worth showing which environment various activities take place.

Build a timeline. Start from the ‘go live’ checkpoint at day 0, work backwards (T-) and plot in the major stages for an average release type (you may need one per model) and then plot other activity: environment management (data refreshes, interface switching etc), comms plan and enough lower level activity.

This high level lets you see the whole picture and start identifying areas of contention. If you have release cycles which last for several weeks and which are implemented monthly, you can expect some overlap. Examine these areas of overlap, it’s not uncommon to find the same teams doing different activities at the same time. Does this work for you?

Continue reading

Release Strategy: Size vs Frequency

Something I’ve run up against several times at several different organisations is making sure that the release process, policy and schedule is fit for purpose not only in terms of being compliant with best practice (such as ITIL) and controls (such as COBIT) and any other requirements within the business, but also to ensure that your change and release structure can cope with the volume of change.

Let’s assume your organisation has two broad categories of changes which are bundled into releases – new business functionality in the form of BCRs (Business Change Requests) and problem fixes.

We’ll also assume that you have a monthly release model which includes:

1. Scope and Design finalisation (1 week)
2. Build & Test finalisation (2 weeks)
3. Running an automated regression pack (1 week plus 2 days for final fixes to go as deltas on top of the main release)
4. Cutover and implementation activity (3 days)
5. Early Life Support (2 weeks) (ELS is an ITIL term which used to be called release warranty – in essence, a period of enhanced support following a release or where incidents/problems follow an accelerated support model compared with normal Business As Usual support).

Continue reading

7 things to be happy about in ITIL 2011

So ITIL has been tweaked. The 2011 edition has been released and contains a number of small to medium ish changes which add up to (hopefully) improved clarity and reduced contradiction.

I’ve actually just ordered the new set of books (at £255 from Amazon – thanks ITIL, thanks very much…) so this post looks at the summary material available from the official ITIL site. I’ll expand on each point once I’ve had chance to review the publications.

1. Standardised structure to improve readability and clarity.

The old ITIL books had some notable differences between them, possibly a product of inconsistent editing across the multiple authors. Grammar and syntax was lacking in places.

2. Lifecycle interfaces and inputs/outputs

A new appendix for lifecycle level inputs and outputs has been added – which is useful if like a lot of organisations you’re implementing in almost reverse order – service operations first, then transition then design. This is useful to allow you to ‘black box’ the preceding lifecycle stage to reduce re-work later on. For example, if you’re implementing Service Transition, it’s useful to know what Service Design would be giving you so you can build the Service Transition processes to cater for this, even if you don’t have time yet to put proper Service Design into place.

3. The ‘Product Manager’ has been removed


This was a role which only half made sense. From my own perspective, a Product Manager was the senior technical person who owned a particular product or application (such as MS Exchange or eg. a bespoke HR application) but really this is just a technical service owner.

4. Cloud computing

‘Some coverage’ has been added to cater for cloud computing, with, presumably, Software as a Service as well as Infrastructure, Platform and Desktop as a Service too. I’m not sure how much value this will add – whether it’s going to be useful or if it’s just a nod to a changing landscape. Watch this space (and check out my other blog

5. Service Catalogue

Updated clarity of transition points and a new status to ‘make policy setting easier’. To be honest, I was fairly happy with the concept of having a pipeline, a ‘live’ catalogue and a ‘retired’ catalogue, but I’ll wait and see. This probably ties in with the next point….

6. The concept of a ‘change proposal’.

This, for me, was one of the biggest gaps in the original v3 and v2 models (well, one of the biggest gaps which seemed to be constrained by having enough definition around the area without actually allowing for it). As I described in a previous post, people don’t just want one high level type of change. Most organisations have a technical type RFC and then a less technical Business Change Request. In fact, RFC and BCR are the two most common acronyms I’ve come across in about 8 different places I’ve worked as a change & release manager. I’m hoping that ‘change proposal’ is akin to a BCR and allows for the woolier type of change request (eg. “I want to accept PayPal” as opposed to “I want to open firewall CORP_PIX_001 to allow connections to”)

7. Release & Deployment management now has a process diagram.

The interactions between Transition Planning and Support, R&D Mgmt, Change Management have always seemed a bit counter-intuitive to me. The addition of a process flow showing how it all fits together should aid understanding.

I’ll post again on each of these points when I’ve read through the official books.