‘So That’s What That Means’ – Observations & Definitions from ITIL v3 Foundation Training

In our personal lives we are all guilty of using words and phrases in a way quite different to how they were originally intended. And we have also, to some extent, had to correct or clarify these misuses in other people in order to make sure the meaning is really getting across. Surely we’ve all had to correct a friend/family member/colleague in the bar/living room/office that “no, the phrase is definitely not ‘for all intensive purposes’” or encountered many grammar enforcer’s personal pet peeve – ‘moot point’ (instead, opting for the admittedly similar but not-always-right, ‘mute point’).

As it is in our social lives, so it is at work; although here the ramifications of something lost in translation frequently have a more tangible monetary value attached to them. Think of the times you have had to clarify if a ‘biweekly status report’ means “twice a week” or “once every two weeks”. Or the times you might have read ‘do diligence’ instead of ‘due diligence’.

It is with this in mind that the North Highland Consulting UK Technology Capability publish this blog post. As part of our commitment to ensure that we continue to offer the ‘best people’ to our clients (who are both imaginative consultants and trained in the latest techniques and best practise) the latest intake have just completed the ITIL v3 Foundation certificate in IT Service Management.

It quickly became apparent to the attendees, all with backgrounds in IT delivery, how much of the technology and project management lexicon is misused or poorly-understood across the Industry.

To try and address some of these lapses (and also to provide a handy reference for the rest of us), here are some of our top ITIL myths & misuses for common terms and themes within Project and Service Management.

  1. It’s a Framework – the framework is subjective and should be applied at the Organisation’s discretion, taking into account a range of factors conditional to them and their external environment. ITIL is not an objective framework to be fully applied under any and all circumstances.  It doesn’t provide all the answers but rather the means to help us find them.
  2. Service Level Agreements (SLAs) – are not a definition of third-party response times (such as a 3 day SLA etc.). Instead, SLAs contain the all of the agreements made between IT and the Business about the provision of a service. These include specific targets, which IT has to meet (such as resolutions to problems within 3 days). Some of these targets may be supported by third parties, in which case third party targets and responsibilities are defined in an Underpinning Contract (UC) between the third party and IT. The key difference is that SLAs are internal agreements that contain targets, and IT has to make sure those targets are met by managing each third party that is involved, using an Underpinning Contract.
  3. Change Management – Change Management should not be something reserved only as a tickbox exercise or for managing changes into Production. A robust Change Management process should run all the way through delivery, giving clear traceability and decision-making from start to finish. Keep the roles well-defined, and empower your Change Manager accordingly.
  4. Continuous Service Improvement – the clue is in the name; it should be continuous and ongoing, not reserved for Project closure. Neither should it be viewed as a magic bullet for improvement; the recommendations from it need to be logged, reviewed and an informed decision made on how to proceed.
  5. Types of ‘change’ – most should be familiar with the concept of a Change Advisory Board (CAB) and the types of changes that pass through it. But what is less rigidly enforced is what a ‘standard’ change means. It is a pre-approved change that has still been through a formal approvals process. It is not a quick way to sneak changes through.
  6. ITIL & Agile are not exclusive – Agile is not a synonym for “do it quickly by missing steps”. The ITIL framework and Agile methodology can complement each other, by selecting the elements of both that work best in unison (backlogs, sprints & CABs for example) you can come up with an approach that delivers rapidly and controls change at the same time, in a way that works for your business.
  7. “Incidents become problems when…” – false. Incidents never become problems. Instead, a problem ticket may be raised to investigate the cause of one or more incidents. Incident Management and Problem Management are two separate ITIL processes, and correct logging of incidents against a problem generate useful MI and trends analysis.
  8. “Problems don’t always have to be resolved” – if you’ve logged incidents and problems correctly, you should have good data on the impact of a given problem, and be able to make an informed decision on whether a good workaround is sufficient, or whether it is worth investing in a permanent fix.
  9. Service Catalogue vs Service Portfolio – these are not the same. A Service Catalogue lists out all of the active services available for use and can be used to identify what is in operation, and aids day to day management and drives efficiencies. A Service Portfolio is more comprehensive and includes services that have been transitioned, services currently being transitioned to the live environment and also retired services.
  10. Agreed ‘downtime’ is not the same as ‘unavailable’ – availability is defined as the ability to perform an agreed function when required within agreed times, not at any time. During periods of agreed downtime such as regular maintenance, the service is considered to be “available”.
  11. ITIL provides organisations with definitive job descriptions – false. There are no job descriptions in ITIL. There are roles and individuals can fulfil several roles as part of their job description. Related to #1, an organisation should define job titles and descriptions that suit its needs. Approaching the organisation of a service management function with this understanding can add flexibility and agility in fulfilling service management functions and maximise the effectiveness of processes.


Hopefully that is a useful list and gives some peace of mind to those who weren’t sure (or should that be ‘piece of mind’?).

Related Reading